thgrund / SuperDirtMixer

Mixer for SuperDirt to provide mixing presets for TidalCycles. This includes level indicators, gain, pan, reverb, compression and eq settings for every orbit (indiviually).
GNU General Public License v3.0
30 stars 0 forks source link

Synth triggered twice during initialization? #3

Open Xon77 opened 3 months ago

Xon77 commented 3 months ago

Hello,

In the documentation provided in the helpfile, I can launch SuperDirt and SuperDirtMixer thanks to the following code:

(s.waitForBoot { ~dirt = SuperDirt(2, s); ~dirt.start(57120, 0 ! 14); ~mixer = SuperDirtMixer(~dirt, 6010); ~mixer.orbitLabels = ["d1 - Lead", "d2 - Bass", "d3 - Key", "d4 - Pad", "d5 - Arp", "d6 - Drums", "d7 - Rhytm Git", "d8 - Lead Git", "d9 - Strings", "d10 - FX", "d11 - Kick", "d12 - Cymbals", "d13 - Snare", "d14 - Toms"]; ~mixer.enableMasterPeakRMS(0)})

Then, a group of an orbit will look like this:

3 group 1046 dirt_global_eq2 1045 dirt_master_mix2 1044 dirt_delay2 1043 dirt_reverb2 1042 dirt_leslie2 1041 dirt_rms2 1040 dirt_monitor2

Now, if I evaluate ~mixer.gui, the group of an orbit will look like this:

3 group 1103 dirt_global_eq2 1102 dirt_master_mix2 1101 dirt_delay2 1100 dirt_reverb2 1099 dirt_leslie2 1098 dirt_rms2 1097 dirt_monitor2 1046 dirt_global_eq2 1045 dirt_master_mix2

And it seems, dirt_global_eq2 and dirt_master_mix2 are now duplicates. Is that normal to have doubled synths inside the group of each orbit ? I've tried to find a way to solve this, but could not find why...

thgrund commented 3 months ago

Hey @Xon77, this is indeed a well know error, that I am aware of. Within the next weeks I will publish a new version that solves this problem and adds a bunch of new features. I am round about 95% done with this new version. You could have a look into this branch: https://github.com/thgrund/SuperDirtMixer/tree/mrreason-setup It just misses one optional feature (the stage master), but is backward compatible and fully usable.

Xon77 commented 2 months ago

Thank you so much for your extension and work! I've looked at your new branch, and the only thing where I see an error generated is when I click the button Bypass of the Equalizer. Sorry if it something already known... Your extension is very inspiring and I am working on a customized version based on your work. I will share it as soon as it works. Thank you so much again!

thgrund commented 2 months ago

I am glad to hear that you like it :-) It can be called a rework of the hole SuperDirtMixer, because I introduced an event system as an architecture to make the mixer more scalable in the development.

I've looked at your new branch, and the only thing where I see an error generated is when I click the button Bypass of the Equalizer. Sorry if it something already known...

I will have a look onto that. Sometimes it works without any problems and sometimes I receive this issue as well. For me it's hard to reproduce reliably. Let's see. If you find a pattern it would be really helpful if you could share it.

Xon77 commented 2 months ago

For me, on Mac, each time I click on the EQ bypass button when it gets orange, I've got a message error :

arg this = ^^ ERROR: Message 'x' not understood. RECEIVER: nil

I cannot find the reason why, unless it has something to do with the EQui GUI. Also, when I click on FX button. When I click on the EQ bypass button to activate it, there is no error message.

Moreover, I've got an error message by following the examples by using orbitLabels :

^^ ERROR: Message 'orbitLabels_' not understood.

Thanks for all and if if you find the reason

Xon77 commented 2 months ago

Concerning the message error "'x' not understood" when clicking in the EQ bypass button, I 've discovered that by changing p.loPassBypass to 0 in EqualizerUI.sc, there is no longer message error. You still can change the GUI for loPassBypass, and it will generate a message that it can send no info to the synth, which is normal, since the EQ synth has been withdrawn / bypassed. I do not know why p.loPassBypass generates an error when it is 1 and then sent to eqView?

thgrund commented 1 month ago

Hey @Xon77 !

Moreover, I've got an error message by following the examples by using orbitLabels

This is explainable, because I changed the interface. I need to adjust the helpfile, but this is how it will work:

~mixer.setOrbitLabels(["d1 - Lead", "d2 - Bass", "d3 - Key", "d4 - Pad", "d5 - Arp", "d6 - Drums", "d7 - Rhytm Git", "d8 - Lead Git", "d9 - Strings", "d10 - FX", "d11 - Kick", "d12 - Cymbals", "d13 - Snare", "d14 - Toms"]);

// Change the label of a specific orbit
~dirt.orbits[4].set(\label, "d5 - Arp");
thgrund commented 1 month ago

Regarding the bypass mechanism, I considered to follow a complete different approach. I hoped to avoid this, because now I need to do a change in SuperDirt. Removing and adding the global dirt effect everytime when someone is clicking on the bypass button worked, but it causes some error messages. I i.e. received the error, that the node does not exist, when sending n_set or n_run. This was caused by SuperDirt, because it tried to change the synth values, even when the synth was freed.

The error that you encountered is different. I assume this happened, because I need to explicitly reset all data after the initialization to have a clean state.

But long story short: with this changes in SuperDirt (https://github.com/musikinformatik/SuperDirt/pull/307) and the latest version of the SuperDirtMixer, I do not receive any issues any more. If you like to try it out, you could install my SuperDirt version that is in review (https://github.com/thgrund/SuperDirt/tree/develop)

Xon77 commented 1 month ago

Thanks a lot for the update!

1 : Yes, the errors, that the node does not exist, when sending n_set or n_run, have disappeared.

2 : The x not understood error with EQ bypass button is certainly due to the fact you mentioned. But, I do not know how to correct it practically.

3 : I've also realized that the FreqScope and also its synth is triggered twice. It might be due to the fact the function createUI of equalizerUI is called twice, one in the initialization, and the other in the creation of the GUI...? I do not how to correct this either.

Thanks again!

thgrund commented 1 month ago

Thanks a lot for the update!

I am grateful that you help me with this debugging, before I release it :-D And you are welcome :-)

1 : Yes, the errors, that the node does not exist, when sending n_set or n_run, have disappeared.

Glad to hear that! Now I need to see, when the needed changes will be merged into SuperDirt. But I am optimistic, that the bypass behaviour for a global dirt effect will be introduced, because there is a similar open Pull Request from the owner.

2 : The x not understood error with EQ bypass button is certainly due to the fact you mentioned. But, I do not know how to correct it practically.

Yeah I am not 100% sure to be honest. For me this error didn't happened. Next Wednesday I have a beta test session with a friend of mine. Let's whether this is something that he encounters as well. Otherwise I assume it has something to do with your setup.

3 : I've also realized that the FreqScope and also its synth is triggered twice. It might be due to the fact the function createUI of equalizerUI is called twice, one in the initialization, and the other in the creation of the GUI...? I do not how to correct this either.

Oh gosh...yes I fixed this in a working state and reverted it. So I already faced this issue. I solved this in the latest version of the branch. Not in the most elegant way, but the EQ ui has introduced some complexities, and I need to create the EQui instance before I can change set EQ parameters.

But, progress?!