Tx81z panel does not work

Home Forums General Using Ctrlr Tx81z panel does not work

Viewing 20 posts - 1 through 20 (of 22 total)
  • Author
    Posts
  • #30030
    reklamchef
    Participant
    • Topics: 18
    • Replies: 40
    • Total: 58

    Ctrlr is able to display a panel with knobs, but those knobs do nothing. A dead giveaway is on the Tx81z panel, which shows ‘chorus’ but there is no chorus on a tx81z.

    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.

    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.

    #30060
    dasfaker
    Keymaster
    • Topics: 80
    • Replies: 793
    • Total: 873
    • ★★★

    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.

    #30170
    reklamchef
    Participant
    • Topics: 18
    • Replies: 40
    • Total: 58

    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.

    #30173
    atom
    Keymaster
    • Topics: 159
    • Replies: 2945
    • Total: 3104
    • ★★★★★

    It’s sending the data it’s just the synth is not understanding it, i just checked this panel (it’s very old) and it works, just the Midi Channel doesn’t get set as it should, i just commited a fix and the new nightly should work, right now it looks like the panel has midi channel 3 hardcoded inside.

    #30188
    atom
    Keymaster
    • Topics: 159
    • Replies: 2945
    • Total: 3104
    • ★★★★★

    An updated version of Ctrlr is ready for download.

    #30196
    reklamchef
    Participant
    • Topics: 18
    • Replies: 40
    • Total: 58

    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?

    #30197
    atom
    Keymaster
    • Topics: 159
    • Replies: 2945
    • Total: 3104
    • ★★★★★

    Just enter edit mode from the Panel menu and modify what you like. No source needed.

    #30203
    reklamchef
    Participant
    • Topics: 18
    • Replies: 40
    • Total: 58

    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?

    • This reply was modified 7 years, 8 months ago by reklamchef.
    #30230
    atom
    Keymaster
    • Topics: 159
    • Replies: 2945
    • Total: 3104
    • ★★★★★

    There is a property for the panel called “Global delay for MIDI messages [ms]” Try it.

    #30242
    reklamchef
    Participant
    • Topics: 18
    • Replies: 40
    • Total: 58

    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.

    • This reply was modified 7 years, 8 months ago by reklamchef.
    #30244
    atom
    Keymaster
    • Topics: 159
    • Replies: 2945
    • Total: 3104
    • ★★★★★

    I just checked, and it is tied to a delay property in the JUCE class, but i need to debug it at home if it’s not broken inside JUCE (JUCE is the library i’m using to write Ctrlr, sometimes things change in it).

    I’ll let you know later today.

    #30251
    atom
    Keymaster
    • Topics: 159
    • Replies: 2945
    • Total: 3104
    • ★★★★★

    So i updated the build again, i fixed some timing calculations, give it a try. Don’t sent anything above 100ms for the delay, i noticed that it just gets unusable and you might end up in a bad situation.

    #30253
    reklamchef
    Participant
    • Topics: 18
    • Replies: 40
    • Total: 58

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

    • This reply was modified 7 years, 8 months ago by reklamchef.
    #30258
    atom
    Keymaster
    • Topics: 159
    • Replies: 2945
    • Total: 3104
    • ★★★★★

    I tested this with the panel’s property, not the global one. Set it to something high like 250 and see if your MIDI messages “trickle” on the interface, maybe you can connect some led or see the activity on the interface somehow.

    When in doubt connect the IN and OUT ports of your computer-midi-interface and use MIDI-OX to see what’s going out and how much.

    #30266
    ELP
    Participant
    • Topics: 0
    • Replies: 2
    • Total: 2

    Moin, atom
    What he mean is, I think one
    Modulator Send Delay between movements(changes).

    Like the snapshoot delay does, but for the modulator(knobs etc.pp) between the movements. So that the messages not send directly after each other.

    For almost every older and sometimes newer Hardware Synth is that a big problem,
    (with SysEx data messages trans!)
    The global Delay function does nothing for that.

    tested 5.2.174 Nb

    • This reply was modified 7 years, 8 months ago by ELP.
    • This reply was modified 7 years, 8 months ago by ELP.
    #30275
    ELP
    Participant
    • Topics: 0
    • Replies: 2
    • Total: 2

    I avoid this a little bit
    (mouse modulator changes to fast and maybe buffer overflow)
    by call
    (just for individual panels and modulators with SysEx data strings)
    a small Lua script.
    Not very effective but it does what it should.

    But, I think, the “sleep” function is only for Windows.(WinApi)
    sleep (millisec)
    sleep and use no processing time.
    For the TX81z around ~50ms is an acceptable value
    Script:
    — Called when a modulator value changes
    — @mod http://ctrlr.org/api/class_ctrlr_modulator.html
    — @value new numeric value of the modulator

    myModSysExDelay = function(mod, value)
    sleep(50)
    end

    • This reply was modified 7 years, 8 months ago by ELP.
    • This reply was modified 7 years, 8 months ago by ELP.
    #30278
    atom
    Keymaster
    • Topics: 159
    • Replies: 2945
    • Total: 3104
    • ★★★★★

    Yeah that’s what the delay parameter in the panel properties does, all messages are delayed by a certain specified time, it’s sort of a GAP between messages. the bigger the gap the less messages will be sent in the same period of time.

    I tested it yesterday and it seem to work. This can’t be platform dependant because it uses a JUCE thread and a JUCE timer to queue the message, any low level OS specific MIDI stuff is done after all that.

    #30287
    reklamchef
    Participant
    • Topics: 18
    • Replies: 40
    • Total: 58

    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?

    • This reply was modified 7 years, 8 months ago by reklamchef.
    • This reply was modified 7 years, 8 months ago by reklamchef.
    #30290
    atom
    Keymaster
    • Topics: 159
    • Replies: 2945
    • Total: 3104
    • ★★★★★

    But, if you sweep a slider from 0 to 127, and Ctrlr will send 127 messages to the MIDI device, your delay is set to 100ms, them it will take 127 * 100 ms (12.7 seconds) to send those message, as each message will be delayed 100ms after the previous one.
    So the messages per second ratio will decrease.

    That’s what i’m getting now, i have a slider, i move it 0 to 127 and in my midi monitor i see that 127 messages are comming in, each delayed in resepct to the previous one by the value given in the parameter.

    #30292
    reklamchef
    Participant
    • Topics: 18
    • Replies: 40
    • Total: 58

    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?

    • This reply was modified 7 years, 8 months ago by reklamchef.
Viewing 20 posts - 1 through 20 (of 22 total)
  • The forum ‘Using Ctrlr’ is closed to new topics and replies.
There is currently 0 users and 45 guests online
No users are currently active
Forum Statistics
Threads: 2,495, Posts: 17,374, Members: 77,605
Most users ever online was 12 on January 22, 2019 3:47 pm
Ctrlr