Remote access to data inside modules.

[marcelodantas]

Hi Folks,

I have recently developed a small patch editor for my Sledge synth using Flowstone.
The Sledge is a stripped-down version of the Waldorf Blofeld, with many parameters unavailable from the front panel, but reachable/usable via SysEx, so I made a small editor to create a patch with modified unavailable parameters which I join into a string (SysEx packet) and send to the synth.
For this I have mapped all the 360+ possible parameters onto knobs, which is working fine.
Now I have a new problem:
As I have laid out these 360+ knobs by using the native FS ones, no input or anything, I am wondering how I could now receive a patch from the synth and distribute the values over the knobs.
I know how to request/read SysEx using FS and etc., that I can do easily ... and I know that if I replace all the knobs with settable ones I would achieve what I want.
However I am wondering if I can avoid the work of doing changes to all of the 360+ knobs, by maybe creating a Ruby element that could deliver the values to all of them by item name, item id or something.
Or maybe some other clever solution.
I am not expecting that anyone would "teach me" FS by answering here, but actually only state if such thing is possible, done before, maybe an example would help, without me going through the obvious process of editing every single knob. Which I will do anyways, in case it can't be done in a simpler way.

Thanks a lot!!!

[Spogg]

I can’t really answer your question, but it seems to me there’s a lesson here. It may be one you know already…

If you get the knob or module right first you can then copy it and paste synchronised as many times as you need.
Now in these synced modules you can change any parameter from the parameter view, so for example you can give each knob a unique preset name and they will still be synchronised. A parameter like a string or float must be set to be a P and must be changed from the parameter view. If you change it in the normal schematic view all the synced modules will update (which can be useful).

Cheers

Spogg

[pshannon]

If I read this correctly, you are hoping there is a way to loop through all components(form.controls) like in visual studio and make changes to each settings like .backcolor ect. It would be a nice feature to be able to loop through all controls like this, but there is a difference here. I do not proclaim to know all the features of FS, but to my knowledge The module "knobs" is built by many smaller units called prims and unless there is a hierarchy, module(name).prem 1,2,3,4 etc / name or id to loop through, I do not know of a way. I do think each item has a unique serial number assigned, if that can be looped through and does the id provide info of the type, can this be leverage? But the actual prem.value is assigned from the next component like a green integer/float box for instance, you would need to grab the value container and assign it to that. Instead of inside ruby, it would be a nice script feature that is interface aware and this way you can script it to get a list of all components on the screen and go layers deep inside modules. The program FS has to have an internal way it stores all this info on where a knob is located on the screen, inside what module and what is connected to what. There are a few people that comes to mind who can say I am totally wrong which is OK or there is a way, but complicated.
I would like to know this as well, it is as I stated a simple task in Visual studio.

Here is a thread a while back on a question I asked about module id:
viewtopic.php?f=2&t=3236&p=17343#p17343

[tulamide]

As I have laid out these 360+ knobs by using the native FS ones, no input or anything, I am wondering how I could now receive a patch from the synth and distribute the values over the knobs.

I'm desperately hoping that Trog will come up with a better plan, because mine is potentially dangerous.

First, you'd need to synchronise all the knobs, similar to what Spogg explained. De-select anything in your schematic, then select exactly one of the 300+ knob modules, then from the "Schematics" menu select "Synchronise painter". Now click once on any other knob module. All modules that are synchronised now show a little loop icon in the lower left. De-select "Synchronise painter" from the "Schematics" menu. From now on, everything you do in one knob module, will be done to all other modules automatically as well. This includes adding prims and modules, and even editing Ruby code.

You'd then add a "wireless module input", name it, and add a RubyEdit. Again, only to one of the knob modules, synchronise takes care of the other ones. The dangerous part would be to use a global in Ruby. This is highly unusual because of the risks. Also, no matter how many Flowstone plugins you later use in your DAW, there will only ever be one Ruby instance running in its own thread. So the globals are even shared among all plugins. In short, you can do more harm than good with globals. However, the idea is that a global would be used as a counter (and thereby giving each RubyEdit in the knob modules an ID at the time of their code execution). Each module will be run after the other, no parallelism. The order of execution is dependend on the layer position and order of adding to the schematic.

I won't go into any more details, because I write this more so that Trog has a chance to let his little grey cells run on full speed to find a less dangerous procedure following this idea.

[marcelodantas]

Well ... nothing like exchanging with gurus.

So, Spogg is right, the lesson was learnt loooong ago when I made my Ableton Push controller. Get the first knob right, do it first, and THEN make 64 copies of it. I will probably just go and re-do the knobs.

For Pshannon, yes, this is what I had in mind, treat the objects as something we could uniquely address and transform/influence. Would be a nice thing to have (if it isn't already there).

For Tulamide, indeed the sync solution is scary, I would have to check, especially because I have the knobs on page tabs, so I wouldn't be able to click on them without first clicking on each tab to go inside.
The Global is also an interesting and dangerous concept, but in my case it could actually work, because my application doesn't process any audio and will not be used on a DAW, but as a standalone .EXE only which edits and transfer patches to/from the Sledge, makes it less prone to destroy the world.

Thanks guys for the ideas, pshannon I will definitely check that thread you mentioned.

Thanks a lot,
Marcelo.

[trogluddite]

Unfortunately; no, there isn't a way to do what's needed without editing all of the knobs, AFAIK.

Access to arbitrary "green" primitives is not possible at all. RubyEdits share an object space which allows them to talk to each other, but they can't be identified by their position in the schematic - by default they just have random IDs which are not consistent between sessions (not even the same numeric order). Communication between arbitrary RubyEdits can be arranged, even if they're not linked - but it always requires some explicit code or labelling for reliably assigning IDs or "registering" them with each other somehow.

However, inter-RubyEdit communication might be still useful in this case, as might a couple of other Ruby techniques - they're not possible without editing the code within the knobs, but might still lighten the workload a bit.

Firstly, if synchronising the knobs is going to be a problem, Ruby might help you to ensure that you only ever have edit every single knob once - even if you need to make other edits later on. There's a way to share method definitions between RubyEdits which would allow you to define the code for all knobs in a single place - the Ruby code would be effectively synced, even if the modules aren't. Cutting/pasting text is simpler than having multiple links and connectors to deal with, too - a Ruby solution requiring no new components or links might even be possible (I stress, might be!)

Here's a very quick sketch of the "code sharing", also including the "auto-numbering" technique which @tulamide mentioned...

share_knob_code_02.fsm

(521.34 KiB) Downloaded 867 times

If you poke around, you'll see that the usual method definitions for mouse behaviours etc. are all inside the shared CodeForOneKnob Ruby definition - the knobs themselves only need to "extend" themselves with that code. Any changes to the methods of CodeForOneKnob will be seen by all of the knobs which have been "extended", even if the modules aren't synced in the normal FS way (a save/re-load is sometimes required).

There are a few caveats to using that technique, but if those "auto-IDs" would work out as mapping to SysEx bytes in a neat way, it might avoid having to tinker with lots of "wiring" between modules, and give a bit of peace of mind that losing module sync later on wouldn't be such a headache.

[MichaelBenjamin]

.

[marcelodantas]

Thanks for the replies.

Yes, after my previous post I started thinking about an "object oriented knob" as the best possible solution.
So it goes towards the idea of having a Ruby master class, or global class, whatever we call it, which I extend to form the objects I want to make multiple copies of.
Which goes more towards the idea of trogludite.
Assigning them a virtual "ID" would actually be a nice idea, based on Michael's. So the inherited classes would receive addressable IDs, and pick events sent to them.
I am now having more fun trying to figure out an interesting one-number-fits-all solution than actually working on my SysEx editor ... LOL.

Thanks guys. Quarantine is not boring anymore.