News and updates

[atom]

Well it’s been a while. I was doing some major changes to Ctrlr. The current nightly has been moved as stable and new nightlies are coming (windows build is there already).
What’s change

1) The way you put components into groups/tabs, no more right click menus, it’s all DRAG and DROP now, just select what and drag it where. It should really speed the creation process i think.
2) The MIDI processing has changes. Each panel now has it’s own MIDI thread that does all the MIDI processing, no more MIDI in the GUI thread. This means that the GUI will have a very small impact on the MIDI timing (it will have some impact sine the messages from the components go to the MIDI thread, so if the GUI will start generating a shit load of messages it might affect other messages in the Thread). This will improve MIDI performance but will also be a reason of many bugs to come.
3) The plugin build has much more HOST/Plugin MIDI options (thru options, channelize options, send to host options)
4) There is a brand new Input Comparator (the part of Ctrlr that is responsible for matching input messages from devices/host to components on the panel). The input comparator lives in the MIDI thread. This is ver experimental and untested in many scenarios.
5) Bug fixes that were reported by people and those i found.

This nightly is extremely alpha unstable untested it might do bad things to you. Be careful with it.

I still didn’t do the Program Manager but as you can see i had my hands full, also i’m unemployed at the moment and my depression is getting to me so it’s a bit hard to do anything. But i’m trying. Let me know about the bugs (witch i’m sure are there).

[etf]

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)!

[atom]

You need to be more careful in a sense that it’s unstable it might crash/hang, there is no danger to your synths. The worse that can happen is you’ll get a SysEx error on the LCD display of your synth and that’s it (that happens a lot with any editor program anyway).

[Tronic]

Here we are ready to test your fabulous work

[atom]

Cool i’m uploading a nightly at the moment, some minor updates (all in the changelog)

[Tronic]

Atom, but some time ago, you could choose between MIDI devices, a device OSC?
or am I wrong? or has been deleted for some reason?
I ask because Reaper has now begun to integrate support for the OSC, and it would be nice to have it.

[atom]

No there was never any OSC support in Ctrlr. I never added this cause i have no test platform for it (don’t really know how wold that work in Ctrlr). I’m open to suggestions on this topic. The network device in Ctrlr was built for remote controlling Ctrlr from portable devices (Tablets, smartphones) but it wasn’t OSC, i still want such a remote control interface to be made at some point so maybe i’ll use OSC, but like i said i don’t know what would be the purpose of OSC in that place.

[dasfaker]

There is a bug with this revision. All custom graphics are scaled to multiple of 8

[Tronic]

OT:

"atom":2516cba3 wrote:

No there was never any OSC support in Ctrlr. I never added this cause i have no test platform for it (don’t really know how wold that work in Ctrlr). I’m open to suggestions on this topic. The network device in Ctrlr was built for remote controlling Ctrlr from portable devices (Tablets, smartphones) but it wasn’t OSC, i still want such a remote control interface to be made at some point so maybe i’ll use OSC, but like i said i don’t know what would be the purpose of OSC in that place.[/quote:2516cba3]

Support for the open sound control, allows to use CTRLR, to realize the control application for a possible DIY Hardware Design, for example a mixing control, lights DMX, etc..
bypassing some limitations imposed by the MIDI protocol.
and having both worlds available, make it unique in its kind

[atom]

"dasfaker":3f0udx8b wrote:

There is a bug with this revision. All custom graphics are scaled to multiple of 8[/quote:3f0udx8b]
This is a Size Snap option for each modulator it defaults to 8, set it to 0 to disable, perhaps i should have made a default of 0, i’ll do that in the next build.

[etf]

is there any chance for a mac upload today?

[atom]

yeah it’s there, i haven’t tested it at all so be careful.

[etf]

thanks ” title=”Smile” />
i’ll give feedback..

[etf]

great 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!

[atom]

Theese are OS priorities for threads, if you set any thread to priority 10 it will be a realtime thread, this means that anytime it needs CPU time it will get it no matter what other threads are doing. It might cause problems, the normal priority is 5 i made it an option cause sometimes a priority 7 is needed (when the machine is heavily loaded). And it can’t be 20 the priorities are 0-10.

[etf]

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. thanks

[atom]

I’ll add a priority setting for some events (notes and midi clock) so that they’re always before all other events in the buffer, that might help a little.

[etf]

brilliant! ” 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)?

[atom]

– if you set the MIDI thread priority to 10 the GUI thread will behave weird cause it’s not getting any CPU time or too little of it, the messages are delivered to the GUI when it gets the time to do so so this might happen, i’ll need to look at this a bit more

– this might be something i need to re-work, cause the automation from the host actually first moves the GUI and then send the message, so this might be lagged if the GUI is lagged, i’ll try to re-write it so that the automation delivers midi first to the MIDI thread then to the GUI

[etf]

-this also happens with standalone/plugin when midi thread priority is set to "0"
-cool that there are still possibilities to change something

[Author]

Posts