Forum Replies Created
-
Posts
-
"atom":lunifyqg wrote:I just need to finish the new threading model and ill post a nightly build.[/quote:lunifyqg]
great! i’m really curious about this update.
(just asking: any idea if the nightly would happen today, also for mac?)[/size:lunifyqg]from my point of view you can delete "look and feel" (i assume you mean this rainbow-button in the main toolbar). i never used it and guess i never will. in generally i don’t need all this optical enhancements.
my priorities for a program like ctrlr would be: stability, bugfree, performance, compatibility, technical and midi enhancements, easy to understand and operate…… and last-named: optical stuff (but only if it doesn’t affect the mentioned essentials!).[quote:2bws33fv]26 seconds is speed of light compared to my 4 minutes!![/quote:2bws33fv]
whoo 4 minutes?? not bad. though the virus snow panel seems to have a lot of graphics and looks complex, btw good work! but 4 minutes are unimaginable for my way of doing songs.
[quote:2bws33fv]Be aware that if you reduce MaxExportedVstParameters to 255 and load 8 panels with 200 modulators, you will need 2040 VstParameters (200 x
to allow automation of all of them inside the daw[/quote:2bws33fv]
my idea was to use several instances/plugins (each midi channel has its own ctrlr instance, not several panels in one ctrlr plugin). isn’t the MaxExportedVstParameter value meant PER ctrlr plugin, or did i missunderstand something?
[quote:2bws33fv]The example project loads in 5 seconds on my pc in debug mode, with a small update i reduced it to 3 seconds. I’ll try to do more where i can.[/quote:2bws33fv]
5 seconds if 8 seperate plugins with this example panel are loaded? very cool that there seems to be something doable!i have to admit that my joy was a bit too early. using the .overrides file did help (i set ctrlrMaxExportedVstParameters to "255" and ctrlrShotdownDelay to "64"), but the (re)loading time is still very huge! i’ve compared ctrlr with other (very resources hungry) plugins – and ctrlr needs muuuch longer.
i used a very simple ctrlr panel (no graphics included) with 200 simple uiSliders (200 parameters for synths like the mopho aren’t too much). then i duplicated this ctrlr instance 7 times to get 8 tracks for 8 midi channels (also not much, "half midi port"). you can find this "test-panel" in the attachment.
now when i save and reload the host project with 8 ctrlr instances, it needs 26 seconds! for an "empty" project with no other stuff inside this is a lot.
when i’m doing the same procedure with 8 instances of any other plugin (i used very hungry ones) the max! time of reloading is just about 4 seconds.so in compare to any other plugin ctrlr needs at least 6 times longer to reload….
i’m almost sure that this wasn’t such a big difference in older ctrlr versions. anyway: is there any chance to reduce this reloading time of ctrlr? would be nice if ctrlr could be "slim" like other plugins. i’m reloading my projects very often to "undo" a bunch of steps. thats why this topic is so important for me. thanks
i see, my bad. thanks for clarification dasfaker. and i already asked myself why there should be a difference between midi notes from the host, or from a midi keyboard!
strange, in my case (mac?) it seems to work with ableton if i set ctrlrUseEditorWrapper to "0" (no wrapper). ableton sends sequenced midi notes thru ctrlr, and also its possible for me to play midi notes with a keyboard thru ctrl…
guess i found it out myself. when i set "ctrlrUseEditorWrapper" to "0" the gui behaves like usual, before it was set to "1" (like it is in the .overrides).
should i set the other functions below also to "0", like in your posted example?oh, many thanks for that instruction, didnt find an answer about this problem and thought there isn’t a solution jet. the loading time is much more faster! though it seems that the plugin gui behave a bit buggy.
– it seems that the gui window is/are 2 different parts (the panel part, and the upper part named "this is a dumb ctrlr wrapper" which you need to click when you want to move the window
– then when you move (drag/drop) the window, just the upper part is moving. and the panel window stays where it was, until you stop moving. then it follows the upper window part.
– if the gui is open and you select another track in the daw, the gui doesnt disappear automatically like other plugins behave. bad is that then (another track is selected) the upper window part disappears which you need for closing the gui. so the gui is always in front of the daw (ableton) until you found its track to close it.it happens with the vst and also with au (at least on mac).
hi, i wanted to answer in this thread anyway. a friend of mine has maschine (mac), and actually maschine [i:ttfl0yhr]does[/i:ttfl0yhr] reading parameter names of all vsts/au, no problem! AND it also does reading parameter names of ctrlr when you take the au!
” title=”Wink” /> just save and reload the project, et voila. it’s only the vst version of ctrlr which makes this "problems". what maschine can [i:ttfl0yhr]not[/i:ttfl0yhr] do is, reading the parameter "value names".
i’m thinking about purchaising maschine, too (or waiting for mpc renaissance?). it also could be a great controller for ctrlr (if i think about the automation possibilities..)-this also happens with standalone/plugin when midi thread priority is set to "0"
-cool that there are still possibilities to change somethingbrilliant!
” title=”Smile” />a moment ago i experienced 2 issues with the lastest version
-when sending more than 1 multi message (nrpn) to ctrlr, this parameters get stucked in the gui (at least visually). i.e., i quickly turned cutoff and resonance at the synth. this causes the sliders in ctrlr moving slowly and irregular, then they stopped moving completely. sysex messages behave normal.
-i made some automations in a 1 bar loop. each time when the loop repeats, the sound of the automation was slightly different. is it possible that the timing for sending parameter messages (cc, nrpn, sysex…) isn’t that tight anymore (though i’m not sure how it was exactly in previous versions)?i see, this makes sense. though it would be nice if it [i:1vw5wj21]could[/i:1vw5wj21] be a bit more tight, but i understand that this isn’t possible (at least not with midi threading priority).
i’ve set the priority to 10 – it’s really better than 5. thanksgreat work atom! seems to be a huge step for ctrlr. i’ll have to test a little bit longer, but 947 feels very stable (except a midi channel bug, i’ll make a report).
2 question about the midi thread priority i have:-are there any disadvantages when setting it up to "10", or why it is possible to give ctrlr a "bad" timing (priority=0)?
-could it be possible in an update to increase the midi thread priority a bit more? it’s MUCH more better than in previous versions, though i think that a double priority amout (20) would make ctrlr very tight.many thanks for your good work!
hi, i’m reading in this forum for quite some time, and i think it’s time to register.
” title=”Wink” />[quote:2cnska8g]This nightly is extremely alpha unstable untested it might do bad things to you. Be careful with it.[/quote:2cnska8g]
though i can’t test the new nightly at the moment (i’m on mac), what does this mean exactly? what could happen (something to the synths?), why i have to be so careful with it?thanks for an answer and ctrlr (hope you’ll feel better soon)!
