Changing parameters makes a device visible

398 viewsCSS Questionsdevice parameters select
0

Hey y’all,

working on my first script and having a hard time getting my head around some of the reactions.

I’ve set up my Beatstep so each memory activates different channels for my encoders, each channel corresponding to a specific track (Eg. RECALL 9 on the Beatstep assigns Encoder 1 to CC 1 on CH 9, which sends data to track 9). I can map the gamillion encoders this method gives me to me gatrillion macros controlling the gazillion parameters in my Live sets just fine using the pre-built mapping types. But as you can imagine, playing around with this many knobs, you quickly lose track of the value a certain parameter was at when you last tweaked it.

Say for example you’re mixing some live audio, and you notice the bass guitar is still a little much in the high parts of the lows. Or was it the lower parts of the low-mids? You start fiddeling with the encoders for your 3rd and 4rd band in your EQ, but notice the sound isn’t matching up to your actions and you start to suspect the 3rd and 4rd band’s frequencies might have crossed over. If only you had some visual feedback to confirm your doubts. But seeing as you still had the keys track selected, the bass’s EQ’s visualiser is, well, not visible. Modern controllers solve this by adding some sort of LED feedback to their endless encoders, but I don’t have that luxury. However, I suspect reactions may allow me to build a fix for this.

What I’m trying to do:

Whenever I change the value of a parameter (through a macro), I’d like for that parameters device to come into view and for its corresponding track to become selected.

I’ve messed around with lists and loops some, but can’t yet seem to get the hang of the syntax and logic. This is what I’ve got so far in regards to the logic:

-Script is initialised->Log all mapped macro’s/parameter’s values.

-Write this to something reference-able (modifier or list?).

-Some sort of script that continuously loops through all possible tracks’ devices and their associated parameters and references this to their logged values.

-When a discrepancy is found between a macro’s/mapped parameter’s value and its logged value, select its corresponding track to bring its devices into view AND update its value in the log.

and because this doesn’t sound complex enough yet:

-Some sort of script that investigates if a parameters’ value is changing because it’s automated by an LFO or anything of the like and thus excludes it from the logic described above, so you don’t get stuck on a track/device that’s run by automation.

A possible issue with my design statement is, what happens when changing parameters in multiple tracks simultaneously? Eg. cutting the lows in one track while bringing them up in another track while DJ’ing?

What I’m hoping for:

Any suggestions on how to get past the automation/multiple tracks issue in my logic would be mint! Also open to design suggestions on the UI design.

And more importantly: If anyone has any examples of how they programmed similar setups (parameters changing bringing associated tracks and/or devices into view) so that I can learn how to set up the reactions from that, that’d be absolutely grand!

Cheers,

L

Glenn Verhaeghe Answered question July 23, 2024
0

The problem with automation only arises if you set Listeners onto your parameters. If you instead set Listeners onto your MIDI Controller, you shouldn’t have problems with automation.

But as you mentioned yourself, when you change parameters on 2 Tracks at the same time, your script will have to set a rule on which device it will show. I’d use a “first come, first serve” rule, with the setup you’ve laid out: as long as the first param you started using is still moving it will show that Device, if you stop moving it then the next param will be the one shown until you don’t move it anymore.

The Action to show a Device can be found in “Live Object Model >> Song >> Select Device”. Use the Path Menu (gray upwards pointing hand) to point to the device you want to select, which you can make dynamic by using Modifiers or any other variable.

The problem I have with your request is that it requires a lot of insight in your Ableton set setup and the way you want to use it. Something of this magnitude is not something I like to tackle. If you could present bite-sized problems as they occur, I’ll be of more help.

As a reflection, if I want to make a complex script, I find it better to first experiment with smaller scripts with specific functions, just to learn how things work.

Questions

Is there a way to link Macro’s on one Track to a Device on another Track?
My thinking is, you could maybe make a Track that’s purely for visual purposes, where each Rack of Macro’s represents a different Track, so that you can see all the Macro’s in one go. Then you only need to have this one Track show on your screen.

Or is there a (M4L) plugin that lets you show all the devices you want to see from all your tracks in a separate window?

Lars Posted new comment August 1, 2024

Hey Glenn,

makes sense using the controller as a listener. Skips the whole having to build a value change logging mechanism for the parameters. No need to reinvent the wheel here.

Seems I might need to revisit the tutorial on modifiers and lists. It hadn’t crossed my mind I could use these to write generic reactions. I was already dreading having to write a script for each and every parameter.

So, some insight in what I’m trying to achieve (documentation included at the end of this post):

I work in theatre, where our FOH desks quickly get cluttered with different laptops running video, surtitles, light, sound and stage mechanics. As a side project, I’m trying to figure out why we haven’t streamlined this yet, as computers have gotten a lot more powerfull than they need to be for a bunch of these tasks. Main reason we use multiple laptops is redundancy and because each program needs its own controller.

I mean, lights have largely moved from dedicated consoles to laptops and nodes. With sound, outboard gear has long been replaced with digital signal processing. And Qlab could technically run everything at once already. But still…

Now, I’ve recently started working with Allen & Heath mixers, or technically, their control surfaces for their mixracks. Basically MIDI controllers with a built in DAW and a big ass soundcard. I have all those ingredients, so I thought I’d try to build one myself. Long term I could use Ableton to relay my commands to all the programs I use to run a show, making one super controller. Thinking about going through a program like TouchDesigner or Max to make the necessary “translations” to fit lights and video into this plan.

I’m starting to realise why the consoles we use are so expensive and why a new one only comes out once every couple of years, it takes WORK to program a thing like this. Almost three weeks into my journey and so far I could do most things I’m doing straight inside of Ableton in a days work. It isn’t really my ambition to succeed in my plan, more to just have fun messing around with it and seeing where it gets me. (Though I have to say, @Remotify Team, CSS is already a pretty nifty program, but the 2.8 layout isn’t very enjoyable to work in. I’d greatly appreciate it if the next updates focus on bringing some “standard” actions to the interface, like the ability to Cmd+Z, Enter to confirm, Shift-select multiple items, organize mappings in folders inside each script, create copies by saving under a new name,…).

As an answer to your questions:

I’ve found this M4L device: https://maxforlive.com/library/device/621/8-control-anything-dials

This will allow you to map pretty much anything in the program to a software encoder, like a macro would inside of a track. But it won’t let you MIDI map to this software encoder inside Ableton, nor can you map it to a macro, only a macro to it. Which sucks, ‘cos I’m using a “master rack” as a “Device 1” in each track, and mapping the effects inside to its macros. This lets me built a rather dynamic script with just the prebuilt mappings in CSS. I can do whatever I want inside of this rack, its primary macros never change place and I can redistribute paramaters on my physical controller by changing which specific macro I map them to inside the master rack. Dunno, sounds complicated, but the visuals in the documentation should help.

https://drive.google.com/file/d/1WuJAKj5Vz9m460NGQClTjuW-crug5xRN/view?usp=sharing

Cheers,
L

Hi, sorry for a late response. I didn’t even realize you had made a comment. I’ve looked into your documentation, mainly the intro and the bottom graphical part, although I also saw the shoutout to my spreadsheet (thanks 🙂 ). If you fear it disappearing at some point, you are free to save a copy to your own drive (anyone is, actually). Also, the depth of Raphael Quast’s Beatstep implementation is really impressive to see.

What I noticed in your own implementation, correct me if I’m wrong, was that there doesn’t seem a way to change parameters of 2 different tracks at the same time, using the knobs on the Beatstep. You need to select 1 of 2 Banks of 1 of 8 Tracks which gives you access, through the 16 knobs, to the macros of the Main Rack corresponding to that Bank on the selected Track. This would mean your worry about conflicts in which devices are shown when changing parameters of different Tracks, as mentioned in the original post, isn’t an issue. Or is it that you would like to have the Devices that are connected to certain Macro’s inside the same Track be visible or hidden depending on which Macro is manipulated? That would be something I could experiment with, see if it works. For example, we only have 2 hands to manipulate knobs with, so we could limit the amount of visible Devices to the 2 last ones that had parameters manipulated through Macro’s and make all the rest hidden. Each time a knob is turned, the script checks if it corresponds to one of the visible devices in the current Main Rack.

If I understood correctly, the Mixer MIDI Controller you use only changes Track related parameters (i.e. the mixer device) so that wouldn’t interfere with which Device is shown either, because all those parameters are visible in the Tracks section. But if changing params via the Mixer changes the selected Track, that could offer interference with the Beatsteps current setting. I wouldn’t give the Mixer control over which Track gets selected, in this case.

May I ask, how did you create the graphics? I’m working on a Nektar Pacer setup myself and might want to make some similar documentation as yours.

Yo Glenn,

no stress, my holidays are over, so this project will become more of a sporadic thing for me. Cool that you’re willing to try stuff out for me, but in my original post I meant more something along the lines of “If you ever wrote a reaction like this, feel free to share”. Not so much “Could you please build a reaction like this for me”.

Sure, my problem is more of a theoretical one than a practical one with the way I’ve set things up now.

I do have a row of “Select track” buttons mapped to the mixer, mainly as a way to arm tracks (-ArmOnSelect in Options.txt).
and as a way to navigate between columns when selecting clips.
(https://medium.com/@ibekso/how-to-expand-ableton-with-options-txt-788e7b9c8020)

If I keep up my interests in this project, I’d like to upgrade the mixer element to something with motorised faders and endless encoders, taking over the EQ’ing duties per track, which now land upon the Beatstep, through this “Select” button the way a Digico or Allen&Heath would.

But you’re definitely right that it isn’t a problem at the moment! If you do still feel like figuring out the “show last changed parameter’s devices” on a per track basis, that would be a cool way to add some of that higher end UX design to this bricolage set-up I’m running. Though only if you’re doing it for kicks! This thread is more me thinking out loud, rather than looking for help with things I’ve properly tried to do but am stuck with. I’m still messing with the setting up reactions to write to the log to learn how each one works, so little nudges like “look into this path” are already tremendously helpful 🙂

The graphics are made with the Affinity apps and a bit of procreate for drafting. Affinity is basically a more ethical copy of Adobe. I payed 270 euros for a lifetime subscription to all their apps back in the day. Their documentation is on par with Adobe’s and the interface is so similar that the transition feels natural. They recently extended their free trial period to 6 months as a response to Adobe’s new EULA, so yeah, I think they’re quite cool.
(https://affinity.serif.com/en-us/)

If you want an open source alternative, Gimp would be your photoshop/pixels approach, Inkscape your Illustrator/Vectors.
(https://www.gimp.org/)
(https://inkscape.org/)

I made a quick sketch of your pacer if drawing isn’t really your thing:
https://drive.google.com/file/d/1vCbMNeK2M3KeA9Cnj-4oo2wnYlSIudt2/view?usp=sharing

Thanks for the images. They look great. Very professional looking with the green detail and everything.

I added the link you’ve sent to the spreadsheet and fixed that one documentation URL you sent me. Your contributions are mentioned in the Log tab. I’m not opening the spreadsheet up to other moderators (I’m kind of a control freak that way) but feel free to send anything interesting my way and if I add them to the file I’ll log your contributions. I could make a duplicate file that’s open to everyone, where anyone can add or change things. Would that be something you’re interested in?

Usually, when I take on a Reaction build, it’s because I see some challenge in it. So yes, it’s mostly out of self-serving interest that I would try to make the Reaction mentioned in a previous post. Trying to see what’s possible.

I’ve looked into it a little and the first hurdle is knowing which Parameter is mapped to a Macro. I haven’t found a clear-cut way to get that info. I might have found a work-around:
– Parameters have an is_enabled property (which you can access through Conditions) and if a Parameter is disabled, that means it is mapped to a Macro. However, it still doesn’t say to what Macro.

So the work-around I’m thinking of is to, upon script initialization,:
– first, save all the values of the disabled parameters and of the Macro’s
– second, have a Reaction slightly change every Macro that has an assignment, and check which of the disabled parameters have changed in value. This way we can link a Macro to a parameter and save it.
– Last, reset all the Macro’s to their value on start-up

This would have to happen for all the Racks on all the Tracks. I wonder how Ableton would take this, if it would stall a bit on start-up until it’s finished, or if the code is so fast that you wouldn’t notice it.

A second hurdle is that you can map several parameters to the same Device, which would mean a potential of having more than 2 Devices unfold at the turn of a knob, which kind of ruins the intentional plan.

A third hurdle would be that when you make new macro-assignments, you need that work-around code to run again on the Rack Device that you’re altering.

To me, it still seems possible but I’m hoping to find a better way to get the list of Macro mappings.

Yo,

totally understand. Documentation is a super personal thing. In most cases it serves as your personal library, where you need to know where everything is at all times to keep your flow.

Sounds like the hurdles are asking to make some executive design decisions. If you map multiple parameters to a macro, it’d usually be for one of 2 reasons, right?
A) A deeply nested parameter gets moved up in the hierarchy by mapping it to macros on multiple levels ’till it reaches the master rack
B) You’re looking to “globally” change a sound, the way a lot of “curated effects” would. Eg. making a sound spacey with a super-space-i-nator you built. It’d add multiple reverbs, delays, …, each with a feedback, rate, size, … mapped to a single macro. In practice this macro would then serve as wet/dry, send, or gain knob for the sequence of effects.

In both cases the end of the chain would be the relevant device to bring up. In case A this is quite straightforward, in case B I’d find it reasonable to expect a programmer to add some sort of utility/gain function in their chain to map to. If you would want finer control of individual parameters inside the devices of a case B, you’d have to allocate a dedicated knob in your master rack anyway, making it a case A scenario.

The script associated with this logic of programming would require a bit of a manual, which I suppose might be a bit antithetical to the idea behind CSS, bringing us closer to prebuilt M4L solutions when it comes to mapping. I suppose I’ve already entered that territory with the whole “Master rack” solution.

Going with my reasoning, wouldn’t the auto select feature for the racks in Live be an interesting tool? It’d automatically open all the devices associated with a sound, if you could then tell the script to navigate to the last selected device in the chain, having it do a lot less work and running smoother.

A tradeoff would be that the devices would be open at all times when a track is selected, and a track will always have to be selected. But these don’t necessarily sound like problems to me