Forum Replies Created
-
Posts
-
it would be great if someone would upload their WIP because then maybe the group could contribute and create. i haven’t a clue how to do it.
i think 3 is the newest. i couldnt figure out how to remove the old one.
i would totally program a panel for the FS1R no problem,
except i have no idea how to program ctrlr, even after reading the one page of documentation.
Or, possibly some other sort of time based sysex ‘choke’ that only allows a maximum of say, a fixed “framerate” of sysex messages that can be sent per second. 30 FPS ought to be enough for most applications when editing the parameters of an FM synth. If you do a quick sweep and send 99 sysex messages in 50 milliseconds, its just un necessary and overloads the tx81z.
so i guess this is going to need to be programmed from scratch.
i think its the amount in a short time when tweaking large incremented parameters too quickly. i believe decimation will work because human interaction still takes time, and the controller messages will be reduced by half if a setting of “2” (throwing away every other sysex message of that specific parameter) is chosen by the panel editor.
and a “send snapshot of currently modified parameter on mouse button release” should make sure the end result is accurate of whatever knob is being tweaked.
the way it works now, is i need to turn the “level” dial of an operator on the tx81z very slowly, else a “midi buffer” overflow will occur. with parameter modulator decimation (throwing away every other sysex message) i would be able to turn the knob a little bit faster. maybe a combination of decimation and delay, carefully tuned, could help address this particular panel.
i wonder if there are other gear out there with the same problem though.
Atom and I have made some very minor changes since then.
My contribution is to remove the chorus feature and move the algos to where they were, and some graphical customizations (edging toward a more ‘realistic’ appearance) with apologies as well as thanks to the very excellent Limeflavour of course. I’m hoping we can see panels as works in progress.First in line is to fix the Midi Buffer Error by tweaking the sysex data throughput, but we shall see.
I would like to eventually like to see the envelope system graphical (with draggable nodes perhaps) if someone could help me with finding a graphic envelope module.
For now, Please see the attached panel and try it out. (edit updated 17 oct 2014)
thanks Atom,
how does one go about making a panel in Ctrlr? Is there a roadmap or a guide? I see a lot of nice panels done, how did they do it?
by ticks i guess i meant an approximate number of times per second, for the purpose of sending a ‘snapshot’ of a single parameter that is being changed or has recently changed only that many times per second, rather than sending each and every increment to the device.
delay in milliseconds still sends an enormous amount of data, just slower. i’m talking about keeping things real time and chopping up the data flow to something like x “frames per second” from a parameter being changed, for when the hardware is ancient.
i suppose this would need its own class, useful for 1) old synths with this problem or 2) knobs with lots of increments where rapid movement might cause buffer problems.
maybe some old gear doesnt have the problem of the tx81z because they might have their own limitations as to how many values it can sense via its own counter?
you are absolutely correct, atom, but i think its no good for realtime control*. better to have a timer of (x) number of ticks per second and grab the current value at those times, and perhaps an ‘envelope follower’ to keep sending values until (x) has elaspsed since the last detected parameter adjustment, so the final state of the knob can be sent.
*by realtime, i mean editing a patch. there should of course be an option whether to control parameters with such a method or the global delay method.
is there already a “send current state every (x) ticks while changing parameters” method in ctrlr?
ok, so the delay seems to work, but its not windowing the sysex messages, (ie: sending say, a maximum “framerate” if you will, in keeping with real time) its putting them in a queue and sending them all in sequence, and the Midi Buffer still gets Full on a rapid parameter sweep from say 0 to 99 on the voice level parameter. if the delay is high enough to avoid the Midi Buffer Full error, it creates a situation where Ctrlr is useless in terms of responsiveness.
the right method for this, i think is to allow a maximum number of parameter controller messages per second, in real time, rather than giving the device a load of hundreds of messages slowly.
make sense?
Installed, and tested, moving parameter knobs causes “Midi Buffer Full”, even after changing the panel’s Global Delay for MIDI Messages (ms) to 50, and to 100. No change.
Could it be the panel or is the General Tab / Global Delay part of Ctrlr?
I will also add “great effort!”
There is a property for the panel called “Global delay for MIDI messages [ms]” Try it.
ok, tried it, and there seems to be no effect, such as in reduced rate of controller messages being sent per second. adjusted to 50, 100, and 250ms and no effect, buffer error persists.
i suspect the property is not tied to anything under the hood.
Just enter edit mode from the Panel menu and modify what you like. No source needed.
aha, just tried that. looks like war and peace 😉
one thing I did notice in using the Tx81z panel is that Ctrlr is sending too much sysex data to the hardware, resulting in the well known “midi buffer full” error on the unit.
perhaps there is a way to limit the rate at which ctrlr is sending midi sysex data to hardware?
An updated version of Ctrlr is ready for download.
whatever magic you did worked. I can now testify that the panel for the Tx81z works in the VST of Ctrlr within Reaper 64bit.
Radical.
is the panel editable from within ctrlr or does one need source files for it?
I have seen this software recommended on several forums, but there is no anecdotal evidence or testimony (example: “it works”) that I have been able to find.
So people on the forums recommend lies? The panels created are nothing more than illusions from the mind of their creators?
This software has been in development for a long time, but it does not seem to allow the transmission of any information at all through my midi interface to my hardware.
It’s clear that you did not set-up something correctly. Post how you config Ctrlr so we can help you.
I’m not calling anyone a liar, I simply have not seen any evidence of ctrlr working, nor have i read of any success stories about it, only recommendations on the renoise, reaper forums. If it doesn’t send any midi or sysex data to the hardware, then it doesn’t work. Let’s see a Youtube video that proves otherwise.
I was excited to find ctrlr, then I was disappointed that it does not function at all. It’s just annoying when people claim something works when it does not.
I am using a Roland UM-1 midi interface, Win764, Reaper, Renoise, and a Tx81z. I’ve tried the standalone, the VST, each day for several minutes, trying all the possible combinations of configuration.
Here is an example of a hardware controller that sends midi controller sysex data to the Tx81z with zero problems. Note that there is no Chorus effect: http://the-all.org/tx81z/programmer.html
I’m challenging the developers of Ctrlr to give proof that it works, because I have found no proof that it does.
I hope this will lead to improvements on the software, that is all.
you are doing really well because ctrlr doesn’t transmit any messages at all to my hardware. i find it hard to believe you’re even getting a signal into your midi interface from ctrlr.
