knob tooltips

[Spogg]

Based on the GUI I see, it looks like there are 6 identical oscillators.

You could create the tooltips for one, delete the other 5, then copy it and paste synchronised for the other 5. Then modify each new osc for naming and presets. This means you only need to make the additions to one module (osc).

Cheers

Spogg

[Nubeat7]

here is a simple example for a central info panel for controllers, it shows the presetname of the controler and its actual value..
it uses my "zero at request module", with this module it is possible to send wireless data from many different sources and only the last triggered is shown..

[RJHollins]

really nice !

Thx NuBeat

[aombk]

thank you for your replies.

spogg, i am planning to check the stuff youve made soon. yes you can freeze tracks in the daw but i have to get the cpu cost way lower. i have started the optimizing process today and i already see a bit of progress.
everything in the synth is synchronized. and the tool tip descriptions are feeded down the module hierarchy to the knobs and buttons and lists by added strings

nubeat7, i think you misunderstood what i meant by "component", but thats ok.
i am constantly browsing the forum the past couple of days to find info and learn things.
(what makes you think i havent figured out, about label boxes backgrounds and fontsizes?)
my goal is to port this synth i have made in reaktor where it works great, and export it to vst so i can share it with people that dont own reaktor. instead of smaller projects, i do extensive tests in flowstone.
but thanks for your recommendations and your help. they are most welcomed of course.

anyway, no matter what i try, the problem seems to be the MGUI mouse moves set to true. for high number of knobs the result is that when there is mouse movement, the synth stops responding visually.
and even though i have seen this behavior in other vst plugins, even commercial ones, i dont like it.

i may try popping up a help bitmap that explains everything when the user presses a "help" button

[Nubeat7]

the problem seems to be the MGUI mouse moves set to true. for high number of knobs the result is that when there is mouse movement, the synth stops responding visually.

i'm very sure that there is another problem then the "mouse move on", i did some really complex vsts with multilayered guis and loads of controllers, (90 % with mousemove on) and i never had troubles..

often the gui makes troubles because of extensive amount of triggers, always try to reduce green triggers as good as possible..

you also should avoid too deep nesting of gui elements..

it would be easier with an example schematic or you extract the GUI part from your project, so its much easier to help you out..

here is a little test with 112 knobs..

[tulamide]

nubeat7, i think you misunderstood what i meant by "component", but thats ok.
i am constantly browsing the forum the past couple of days to find info and learn things.
(what makes you think i havent figured out, about label boxes backgrounds and fontsizes?)
my goal is to port this synth i have made in reaktor where it works great, and export it to vst so i can share it with people that dont own reaktor. instead of smaller projects, i do extensive tests in flowstone.
but thanks for your recommendations and your help. they are most welcomed of course.

That's an important point. Reaktor in its core is a modular synthesizer. Therefore it already did the hard task of optimizing for you. In Flowstone you create real VST plugins, which means it can't do any optimizations for you. That becomes now your part.

The biggest issue is that people don't realize how many triggers are generated (it is an awful lot!). And triggers propagate through the schematic. Worst case scenarios can produce thousands of triggers from just one. So, first look for redundant triggers. Also, reduce the amount of draw triggers. Try to keep them at 25 per second the most. That's more than sufficient, because you don't develop a game.

A typical trap you might fall into: Say you have a bunch of parameters that control one action. That means the action is to be performed when all parameters have been updated. But every green line sends a trigger when a value changes. In our scenario that would mean, all parameters send a trigger each, thus performing the same action a bunch of times, where only one time would be needed. For those cases you need to catch all the triggers and only send one, after all parameters are updated.

And that's just one of many traps we can fall into. Optimizing is the most important part of creating a plugin.

[Spogg]

Maybe this can be clarified for me:

On a few occasions I've had controls that are "sticky" in Flowstone but work as smooth as silk in the exported VST(i).
I assume this is a trigger avalanche in FS but why doesn't this happen equally in the exported VST? Is this optimised during compilation by FS for example?

My most recent example of this is the Quilcom Mistress and it affects the meter-scope level displays and the vu meters as well as the controls which tend to jump unless moved very slowly. But not in the VST export.

Cheers

Spogg

[tulamide]

On a few occasions I've had controls that are "sticky" in Flowstone but work as smooth as silk in the exported VST(i).
I assume this is a trigger avalanche in FS but why doesn't this happen equally in the exported VST? Is this optimised during compilation by FS for example?

It does happen in the exported VSTi, you just don't notice it anymore. That's because within Flowstone you work in edittime. Flowstone hooks in to everything you create to keep control. That's a lot to do for Flowstone. However, in an exported plugin there is no need for any Flowstone control. So this overhead code is not part of the export, which gives the plugin more cpu time to work with - and therefore a way to deal with the trigger avalanche better than in Flowstone.

[aombk]

thanks.

Nubeat7, my synth currently has 412 knobs 99 selectors and 72 on/off switches. these are the things i would like to have tool tips for. so i added knobs to your test and it demonstrates the same behavior for me. also if you export it as vst and try it in a daw, when you move the mouse the daw visually freezes as well (if you turn mouse moves off, it works smoothly). does it behave that way for you too?

on the other hand, the knob in your test costs less cpu and is much more efficient than the one i use. maybe i just used a bad knob as a basis for my knob, i dont know. i will definitely look into that.

thanks for your help.

tulamide, yes i know. i am not comparing reaktor to flowstone. i understand they are different software. you just can do similar things with them.(though with the introduction of core environment for reaktor you can extremely optimize your ensembles)

i will look into your suggestions, they make sense. thanks for the help

[Nubeat7]

Nubeat7, my synth currently has 412 knobs 99 selectors and 72 on/off switches. these are the things i would like to have tool tips for. so i added knobs to your test and it demonstrates the same behavior for me. also if you export it as vst and try it in a daw, when you move the mouse the daw visually freezes as well (if you turn mouse moves off, it works smoothly). does it behave that way for you too?

yes, i get the same here, looks like this is just too much, you could try with multilayered gui to reduce the nr of controllers on one gui tab...

anyways if you set mousemove to false my info panel still works but only if you move the controller

btw. 448 controllers without any direct or intuitive info in one tab is just a pita for any new user, also if you have your info panel you always would need to search for the right controller, for me this would be a reason to abandon the best synth ever..

i know if you are developing something you know your tool but others don't..