proof of concept, one mouse area, one multidisplay, one synth

MvKeinen

cheers,

I wanted to show you the current state of my big project, maybe get some feedback and ideas, discussions.

I could also describe some basic functions if there is interest. There are a lot of mechanics that might be interesting for people.

I also will use this thread to announce updates and get opinions.

be sure to read the description:

https://www.native-instruments.com/de/reaktor-community/reaktor-user-library/entry/show/14883/

MvKeinen

also big thanks the @Quietschboy for ACEW!

MvKeinen

Next update is ready!

Update history

v0.56

- added multiplication of fader increment

- added right mouse operation for faders

- added fine tuning for faders

- added central display of parameter names and values

- added multilayer editing, see Sequencer 1 edit A&B

- added univerasal ID. Now every graphical element can be modified by up to 4 data entries. Example: Note name display inside the piano roll editor. See snap 001, change root note. It can be modified by the zoom, the edit switch, the root note fader and the note edit.

- fixed display of note names in the piano roll editor

- fixed (finished) numerical readout

- some minor fixes and improvements

MvKeinen

This is a rather big update even if there is no added eye candy. Two big additions in one update! Multitimbral polyphony is working! Automation is also working but I'll need someone to test it because I rarely use VST hosts. Activated for automation are the 6 horizontal fader under view: LFO & Env for all 4 channels. that makes 24 automateable parameters.

v0.57

- added multitimbral polyphony (check channel switch A/B/C/D)

- added automation

- some minor fixes and improvements

MvKeinen

so here is the automation thing:

Normally I use the computer only for recording hardware and reaktor coding, so I'm not really sure about the expected behaviour of automation in the VST host. As I don't use standard panel elements I have to use the primary automation module. I wish there was an automation array module in R but for that we would need access to the parameter ID. I think i got it right in the last update (link in OP) but I'm not sure. In Reaper recording of panel movements works. Also the 24 automate activated parameters show up in the list and the display reacts to the automation. If you edit an automated parameter the stream from the host stops at that parameter and the display shows the edited value. (thats what the "Tch" input of the automation module does).

Does the automation of the host always completely override the parameter of the plugin or is there a mode that does it relative the the parameter setting? I ask because it should be possible because the data is always sent to the host. What about snap changes? should the Parameters be sent to the host on Snap change? I'd have to connect the "G" output of the SVA to the "Tch" input of the automation modules.

I noticed another bug when switching the channel from automated parameters to non auto parameters.

So it would be awesome if someone could take the time, download the ensemble open it in his host and check if automation is working as expected. Switch view to "lfo & env", those horizontal faders are enabled for automation. They work for all 4 channels A / B / C / D. So a stress test would be to switch trough all channels and automate all 24.

Questions:

1. Does it work?
2. is it practical to have the whole fader moving or would it be better when an extra element pops up when automated to show the movement? With modulation I'll have to do that anyway.

the system allows me to add any parameter related element into the animation. If you want to check it out simply do this:

now, also the numeric readouts react to the automation. this is of course a bit costly and might be irritating in the long run. The whole implementation of automation is quick and dirty right now as in too many display elements are triggered. So right now I'm trying to find out how to display automation in the best way. Any input is highly appreciated.

It will be also for the community as I plan minimum 2 UL uploads with this. But as you can see it is still a lot to do before that.

Quietschboy

Hi MvKeinen,

nice project! Unfortunately i can´t open it as i am stuck on an older OS.

I can´t tell much about Automation, only some thoughts:

Usually, automation is absolute. The knobs/faders in your multidisplay should follow the values like "real" Reaktor knobs would do.

Otoh, as you use the Automation module for automation input instead of knob module, this opens the posibillity to use automation as a modulation source. If you do it like that, then modulation bars similar to the modulation rings around the factory blocks knobs are indispensible, imo.

PS: You said it is costly to send the values to numeric modules. I hope you latch all GUI-only outputs by display clock before Core Cell outport?

MvKeinen

Thanks @Quietschboy !

I put in a break for this project, but will resume it soon. Luckily I've made a good documentation so it won't take long to get back into it.

I've decided to use automation in an absolute way. The problem I anticipate is that I'll have to use a LOT of these automation modules. Around 50 parameters with modulation A/B would get me 150 of them. That in itself shouldn't be the problem but to keep the structure clean, I want to send the outputs of them through a {bus} and I've never done that with signals calculated by the audio thread. Tests with 25 automation modules went well but sending 150 signals at control rate through one wire seems a bit crazy. Will have to figure out a test ensemble to try this. But I have no idea how to set that up in order to look for drop outs. Does anyone have experience in this? Generally about sending a lot of streaming control signals from the audio thread through a bus?

thx

Quietschboy

What i can say about bus systems in general:

• Performance decreases with the total number of Receivers in a bus.
• If the input events were released either from GUI or Audio Thread doesn´t matter. BUT:
• Do NEVER mix GUI- and Audio Thread events into one bus. This will produce Thread problems. (I am assuming the Thread topic is known and that it must not be confused with audio events). Of course this could be problematic when transmitting Panel Element Controls controlled by mouse (GUI Thread) and MIDI/OSC (Audio Thread) at the same time via one bus. If i remember correctly, Automation arrives in Audio Thread, but i can be wrong?!
• For simple Send and Receive busses it is absolutely safe, often cheaper and easy to maintain simple INDEX [], VALUE $ busses. Each message contains one value. If you want to do more complex things like merging or so, the Partial Framework Bus by Max Zagler is a very solid solution. This system is well thought out and Max paid great attention to safeness. The message size is flexible. You can send as much values as you like in one message, which in turn could be cheaper than the simple bus. A message looks like this: ID, NUMBER of following events #, []1, $1, []2, $2...[]n, $n.
• A bus system can do more than you might initially think. As i said: The number of Receivers in a bus chain make the costs. If it´s too much: Split the bus in two or more.

At which rate does the Automation Module send events? Is it at Event Rate (when they arrive) or downsampled and output as a Control Rate Stream? However, i can´t think of such an DDoS like stream coming from Automation that it would suck your CPU, still when using a bus system. I do not say it doesn´t matter, carefull and thoughtfull programming can´t be wrong. But, if we are just talking about changing a synths parameters? No.

It sounds like you want to transmit Control Rate Outputs, like from a (Primary) LFO or a (Primary) ADSR inside the synth via bus?

Quietschboy

Instead of checking the bus systems CPU load by connecting and sending high rate events on all 150 Automation modules, try a simple iteration on a setable rate and event amount ;-)