@schlam I am able to try it as soon as I get back home from our workshop
Regarding these last updates of the editor, since there is not an RCnn version to confirm if we are using the latest (I am testing on three computers, so one gets easily confused)
Let me suggest to mention the date of the release when you open a thread with a new version, so we can easily check by the date the file was created
Yes, of course, since the editor doesn’t mention the RC version of the Fw, it’s hard to be sure =)
But I really downloaded the good files, and I tried twice. I have the good version of the FW and the editor and I followed the procedure.
Maybe my problems doesn’t come from 'the mooOog stuff", but, by the way, my problem is…
So I have to understand that when, on your own, you switch on the MIDI SYNC and the LFO KEY TRIG, the LFO is well trigged.
Here : it’s not.
Maybe the problem doesn’t concern “moog”, but here it’s not working…
GilW said “What component of the Editor are you using? Is that VSTi (instrument) by chance ? does it work with VST?”
–>In my setup, the standalone editor is used only like a “screen”. Everything is controlled by max/msp, I never touch the MTR or the MTRE. it’s only receiving lot of sysex and midi data in the same time.
Maybe the problem comes from there… I am only talking about the standalone version of the editor. i am not using at all the VST ot VSTi versions…
So, to answer, I don"t use any “component” of the editor.I only send CC / PC /sysex messages to the MTR and everything is perfect but the MTRE doesn’t response.
In this case, max/msp is programed to send to the minotaur CC information, and, when I send the CC to switch on LFO KEY TRIG, it’s never working if MIDI SYNC is set to ON.
If MIDI SYNC is off, sending CC value for LFO KEY TRIG make it working good…
(excuse my bad english..=)
I am currently making this test. I understand you mean KEY TRIGGER when you speak about LFO TRIG
When making the test with the standalone Editor and an external hardware clock (OP-1), this works as expected.
I also made the test using Live as master clock, the Editor as VST instrument, and it works fine as well
The OS is the same as yours, and I also have Renoise, Bidule and MIDI-OX to test.
I am able to download any freeware/demo to try with something else. What DAW are you using?
If you first install 2.1.1 and then upgrade, there’s no reason why the update would be made to a wrong version.
I only use Max/Msp 7 with the standalone MTRE..
Are you able to send us the project or patcher where the problem shows up?
I’m still not sure what your setup is… but please note MIDI SYNC is meant to be used mainly in DAWs, so LFO Rate is synced to the DAW bpm.
For program changes in standalone, you’ll need to send it via DIN IN and turn Echo DIN->USB on.
Hello,
No need to send you the patch because it’s not working even without it.
Just with the editor in standalone it’s not working.
But I found out what is the problem.
And I still don’t know if it’s a wanted behaviour.
Yes, when the clock is sent in the DIN and the MIDI SYNC is on, the LFO Key Trigger is working good.
But if the MIDI SYNC is on but without clock sent, the LFO KEY TRIGGER doesn’t work.
In our configuration, I am receiving a midi clock signal from an other musician.
So a midi cable is always plugged in the MTR DIN, but my friend is not always sending clock to me…
In fact, the procedure is :
-send a midi clock to the MTR by the DIN
→ MIDI SYNC and LFO KEY TRIG are working good
-let the midi cable in the DIN but stop sending midi clock and let MIDI SYNC to on
→ LFO KEY TRIG is not working anymore until the MIDI SYNC is switch off…
You can reproduce that ?
Yes I know it’s working with this method, but as I said, I have to let the DIN of the MTR available to receive a synchro which cannot be sent via USB.
So, you confirm me that the MTRE doesn’t receive programchanges via USB but only via the DIN…it’s a bit sad =)
It receives Sync via USB when used as a plugin. When using the standalone, the USB ports are used to make a connection between the plugin and hardware, so you basically cannot share the ports with another program. It might be able to receive sync via USB when the Editor isn’t using the ports, not sure have to check.
I could reproduce this on the standalone version by sending the Clock via MIDI over USB and routing using MIDI-OX.
Even the LFO rate stops working if the playback is stopped. But, I don’t consider it a bug, or is it?
This is something that we’ll have to check when/if going about making any future update to the firmware/editor. At the moment we’re focusing on preparing this version to production.
Maybe it’s the right time to tell that we basically approved 2.2.0RC11/3.2.0RC17 for release! 
I still have to make a couple of tests tonight on Snow Leopard (I am the only one testing that here, ain’t it), on Windows 7 everything looks good
Should I take the unit to our workshop to test it on El Capitan if all looks good at home?
Yes, if possible. Only to eliminate any chance for new “surprises”
Thanks !
Yes, I share in the same time the USB port with the standalone editor and max/msp and in this configuration :
-the MTR is well receiving datas from max
-the MTR is well receiving datas from the standalone MTRE
-standalone MTRE is well receiving datas from MTR
-max is well receiving data from the MTR
-max is wellr eceiving datas from the Standalone MTRE
-but MTR doesn’t send data to standalone MTRE when they come from max
To avoid that behaviour, in max/msp, eachtime I send datas to the MTR I send just after the sysex message which make the MTR ourputting all the CC values, and then the standalone MTRE catch them.
The only problem is about the programchanges.. the sysex message F0 04 08 1B 00 00 F7 only output CC and not PC…
So…maybe in a future update =)
The beta versions of MTR firmware and editors will continue after the release or you plan to only work on others devices for a while ?
In all cases, thank for your work !
This configuration isn’t really supported, and I wouldn’t expect it to work right anyway.
I’ve documented your report for future reference though.
Thanks!
Here the LFO rate doesn’t stop to work and I don’t know too if it’s a normal behaviour.
It’s just for me very annoying in our configuration…=)
I confirm the following behavior:
Unfortunately it’s too late for 3.2.0, but it’s documented.
Thanks.
LFO works during playback when slaved to MIDI Clock.
But, after MIDI clock stops, this parameter is freezed. If you turn off MIDI Sync OFF in this scenario, LFO Rate works again
I made some tests during the weekend and I found some limitations on Snow Leopard, running Ableton Live 9.1.10 / MIDI Patchbay with standalone Editor:
Using standalone Editor or Live:
I see that the parameters which are being controlled externally don’t move on the screen unless they are sent from the Mintaur itself
But, those moved from external CV do move on screen
Limitations on Live 9.1.10, OS 10.6.8 but not on Windows 7:
When I opened the plugin window during playback mode, the audio stopped on the Minitaur
I need to create a second MIDI channel for notes inside Live, which I don’t need to do on version 9.7.2
Relative mode does not work, the values jump directly whichever setting has on Knob Mode
I am currently testing on El Capitan and hopefully will report if there is something else later today