April 26, 2011 at 10:13 am #341
I like to have a bidirectional communication between Ctrlr v5 and the synth. So that I can control the synth with Ctrlr and vice versa. That means I’m forced to connect the MIDI in AND out.
After a while of tweaking knobs I’m always experiencing that the communication from the synth (e.g. Tetra) to Ctrlr get stucked. Then I’m forced to tweak the parameters of the Tetra very slowly, otherwise both (Tetra & Ctrlr) are doing nothing anymore (I also notice a big delay). From my experiences this is a sign of MIDI feedback, right?
Is there a way to avoid this feeback – Maybe some kind of "don’t send incomming messages to the output" function? Or am I on the wrong track of thinking?April 26, 2011 at 12:32 pm #2678
well i’m going to add this function since someone else requested it. But the synths i tested so far (Korg ms2000 and DSI Mopho) don’t cause this it’s really hardware dependant. But i’ll try to prevent that on the Ctrlr side.April 26, 2011 at 1:12 pm #2677
You’re right, it depends on the synth. I’ve tested it with a Virus C – there it works much better. The Tetra gets this problem immediately (before I thought it happens only after a while). Maybe Sysex vs. NRPN? Anyway, adding this function would be great!April 26, 2011 at 1:20 pm #2676
yeah i just need to figure out some clever way to predict feedbacks. It depends on the OS in the synth, Evolver has a special setting for that, other synths are simply clever enough no to re-transmit a midi message if the incomming midi message does not actualy change any value (it’s very simple, synth has value 0 you send it value 1, it changes 0->1 and sends a midi message, you receive that message and set 1->1 and either re-transmit or you don’t, at the moment we do, but then the synth receives 1 and does not re-transmit any changes since it already has 1)April 26, 2011 at 1:57 pm #2675
Ah ok, that makes sense. Wouldn’t it be enough that Ctrlr "just" blocks it’s output when it gets external controlled? So that if there are any messages on the MIDI In (of Ctrlr) recognised, that Ctrlr cuts/breaks/filters them – and they aren’t send to Ctrlr’s output. Just a nonprogrammer naive thought…
EDIT: ok – i was wrong. At the latest when Ctrlr gets automated… problems will appear when you like to do additional tweaking.May 10, 2011 at 12:45 am #2679
what synth are you using? does it not have a MIDI thru setting?? If you want to prevent messages coming into a synth from going out the midi output port of the synth the standard method of handling this is to turn the midi thru setting on your synth/sampler/device to "off" or "out".May 10, 2011 at 1:54 pm #2674
My DSI Tetra is affected by this feedback strongly. But I’m confused. As far as I know MIDI thru is for chaining multible MIDI devices – if you don’t have enough MIDI ports. Of course if you send then on an other MIDI channel (to control an other MIDI device) – the "source channel" of the first synth isn’t affected. The Tetra has MIDI In/Out – but I can set the Out to Thru, but then again it doesn’t send it’s internal MIDI messages to the out anymore (and this seems logical to me)… Even if the Tetra would have an seperate Thru port – how should I connect it to obtain a bidirectional communication? Did I missunderstood you?May 10, 2011 at 11:10 pm #2680"minimalist":7yufkbfr wrote:how should I connect it to obtain a bidirectional communication? Did I missunderstood you?[/quote:7yufkbfr]
MIDI INTERFACE MIDI OUT
> SYNTH MIDI IN
MIDI INTERFACE IN <
SYNTH MIDI OUT
Turn midi-thru OFF on your synth otherwise the signals coming into the synth will be sent directly back to the midi interface and introduce MIDI feedback.
That’s it ” title=”Smile” />
If this is how you have it connected and your synth is still getting stuck as you’ve described it I’d suggest first disconnecting and powering off any other midi devices you might have plugged into your midi interface.. it’s easiest to troubleshoot issues when you reduce the variables.
Then you need to experiment and find out:
When does this issue occur? After you tweak a knob on the Tetra or after you tweak a knob in CTRLR?
What are the activity lights on your MIDI interface doing when you are experiencing suspected "feedback"?? If there is indeed a midi feedback loop typically the interface lights stick on until a MIDI Panic message is sent.
It is very possible that what you’re experiencing isn’t actually midi feedback… are there any parameters you’ve created a slider for in CTRLR that cycles through settings, where on the actual piece of gear it’s a selection made with buttons, or a jump from one parameter to another no matter what the controller’s value?? On the XT panel I’m making I experience a bit of lag when cycling through the wavetables – this is normal as MIDI is a slow protocol… I actually see better performance when I change that wavetable knob to a wavetable selector box, for instance. . .
I hope this helps, good luck!May 11, 2011 at 4:34 pm #2673
msepsis, I appreciate your effort. But the question how to connect the synth was meant rhetorically, because as I already wrote: I use a Tetra and there are NO settings for "Thru=OFF". I only can set the MIDI out to "Out" or "Thru". Because (it’s logical for me) the setting "Thru" prevents that MIDI messages are sent to MIDI out – this makes no sense. ” title=”Wink” /> To answer a few questions:
– this "feedback" (stucking values) only appears when the Tetra controls Ctrlr – not the other direction
– every parameter is affected – not only "selection buttons"
– while this stucking appears the MIDI In/Out LEDs (on the interface) are activated (logical: It’s a bidirectional connection). But the LEDs doesn’t stick (they are off when I stop tweaking a knob).
– when I’m tweaking a knob very slowly everything works as usal. But when I like to tweak a know a bit faster, the value sticks at a certain point
Appart from this: Can someone else confirm that MIDI Thru is for avoiding feedback?? I’ve the feeling that the Microwave has some special settings which other synths don’t have – maybe this confuses this discussion?May 11, 2011 at 4:57 pm #2672
MIDI thru is NOT for avoiding feedback. what it IS for is to route the MIDI input THRU the output. Enabling it CAN introduce feedback in certain situations, which is why I went down that path. It’s hard to diagnose someone’s issue w/o having the full picture…
"Is there a way to avoid this feeback – Maybe some kind of "don’t send incomming messages to the output" function? Or am I on the wrong track of thinking?"
.. and.. well.. turning off MIDI thru is the common solution to that.
I see that you only experience this when sending messages from the tetra to ctrlr so MIDI THRU sounds to have nothing to do with your situation.
It sounds like Atom was already looking at this so I’d just sit tight. ” title=”Smile” />May 11, 2011 at 8:17 pm #2671
In your first comment you wrote about "the [i:oql6676q]standard method[/i:oql6676q] of handling this is to turn the midi thru setting…"
Now you write "Enabling it CAN introduce feedback [i:oql6676q]in certain situations[/i:oql6676q]"
And I can "just sit tight", no problem. It wasn’t me who recalled a 2 weeks old thread?
But for sure we completely missunderstood eachother – nevermind & thanks for your help so far (honestly).May 11, 2011 at 9:12 pm #2685
i’m working on that issue (it’s all connected so the vst automation stuff and this are one thing), this should be fixed later on. I just found that my magic input matching algorithm isn’t that magic after all, i need to work on that a bit more.May 12, 2011 at 12:06 pm #2684
Yeah, this "total integration" thing could be very cool. Nice that you be on it!
I did some more tests and find something out, don’t know if it’s helpful:
This problem only appears when the Tetra’s KnobMode is either set to "Passthru" (snap) or to "Relative". If I choose KnobMode = "Jump" there are no problems at all!
… The Virus’s KnobMode doesn’t seem to change this behaviour (in all releases before build 450 everything worked perfect with every KnobMode, but not since 450 – as you know).
Even if this information isn’t helpful – it’s nice that there is a workaround for the Tetra (KnobMode=Jump).May 14, 2011 at 2:16 am #2681
Do you happen to have any other MIDI in devices enabled in ctrlr for your panel?
Something interesting I just noticed here..
I plug a korg nanokey into my pc, (usb) verify the midi settings in the korg editor, sending on midi ch1.
Open "devices", set the nanokey as a midi in device, my dinky midisport port A as the MIDI out (which is connected to the waldorf microwave Xt)
I open my microwave xt panel, set the MIDI input device to the nanokey…
If i hit a key on the nanokey OR if I hit a key in the ctrlr device’s panel my xt locks up HARD.
I’ve never seen the xt lock this hard, sending an all notes off or panic does nothing from the XT, at this time my midi interface LEDs are all dark indicating no real MIDI feedback, just a locked XT. I have to actually unplug the xt, even holding power does nothing. yuk.
I thought I’d just add this experience to the thread as it might be a shared experience?May 14, 2011 at 11:25 am #2682
Hmm, that’s really weird – can’t explain it myself what happened there. In my case I only use 1 MIDI port which is dedicated to MIDI in/out of the synth. MIDI notes doesn’t go through Ctrlr – I’m sending them directly from the host to the synth. Does this problem still appears when the nanokey is disconnected – and you send MIDI notes directly from the panel? Is just the MIDI in of the nanokey activated (in Ctrlr) – and just the MIDI out of the midisport? But these are only some helpless shots in the dark… Sorry, absolutely no idea what this can be.May 15, 2011 at 5:29 pm #2670May 16, 2011 at 2:53 am #2683
Very nice update, atom! The "feedback" problem with the Tetra/Virus seems to be completely solved… thanks a lot!December 20, 2012 at 12:38 pm #5211
Old thread bumpage —
I am looking for a way to avoid sysex feedback loops.
Most of the time it is no problem that ctrlr gets a message it just sent out, because if it is some kind of response string it does not trigger anything when it is re-transmitted.
But for example with a preset dump request this kicks off a neverending loop because the dump request message gets mirrored every time; eg it goes out, goes in, out again….
I have already tried “anticipating” this kind of loop by listening in the midiReceived script and doing *something* in reaction, but until now all i tried does not work.
Ideally this *something* would be to filter out the received string from traveling to the midi output again, is this possible?
The setup is as follows:
sampler midi out ->pc midi in -> CTRLR panel -> pc midi out -> sampler midi in
Since sysex is channel independant channel settings do not matter, and toggling thru settings in ctrlr just makes it worse (obviously), doubling the received data.
The sampler always sends out received sysex events to the midi output again so i cannot “dam them in” on the device itself either.December 20, 2012 at 10:36 pm #5226
Create a customComponent as a button, and in the MouseDown method send the dump request message. This component will ignore any midi in message, it will only send the dump request with a mouse click.December 20, 2012 at 10:51 pm #5227
Only just found this post..I get feedback with my XT too..I don’t have any MIDI thru connected anywhere nor do I have it set in ctrlr..I never use MID thru..
I’m not sure what causes it to happen..It seems to happen while I’m not even editing the XT..I might be using ctrlr to edit my MKS for instance, I’ll go to change patches on the XT and it will have locked.
I connect all of my synths MIDI in and out as I like to write sysyex in Logice and I also use MidiQuest..
I only set MIDI in and out (and tick MIDI to comparator – don’t know what that is!) Never use MIDI thru in either Logic or ctrlr
Didin’t realise it might have been ctrlr doing it..thought I had a bum XT.
The MKS does it after I have changed to a split patch with the PCProgrammer..I play the bottom half of the split and bang. Locked..Can play the top half fine
You must be logged in to reply to this topic.