Please see the following Minitaur release candidate firmware v2.1.21.
Please download, install and test it thoroughly, reporting any issue which may arise. If no critical issues are found, we will use it as the official v2.2.0 which we plan to release soon.
OSX users - please use the provided firmware updater (open by Control->Rightclick->Open).
NOTE: The updater will report an unsuccessful installation, although firmware is successfully installed. This wrong message will be gone once we set the firmware version to 2.2.0. It will also report wrong “current version number”. Please ignore them both.
Enter bootloader mode: Press and hold VCO1 Wave and VCO2 Wave switches, and while keeping them both pushed plug the power cord into your Minitaur unit. Keep holding the two switches and press the Release switch, then release all switches. You should see the Glide switch LED blinking slowly, which indicates that your Minitaur is now in bootloader mode.
Connect your Minitaur to your computer using a USB cable. Please connect it directly and not using any hub. If Windows starts an automatic driver search, let it install the default drivers.
Load the C6 sysex program and configure C6 midi ports so they point to Minitaur In/Out (“CONFIG”)
Load the ‘Erase Firmware’ file provided in the firmware zip, into the C6 program (“LOAD”)
Click SEND. VCO1 Wave switch LED should blink as the old firmware is being erased. Once completed, VCO1 Wave LED should go dark and Glide LED should keep on blinking slowly.
Load the firmware sysex file into the C6 program and send it to the Minitaur (“SEND”). As the syx file is being transferred, you should be able to see the Midi LED blinking rapidly, and VCO2 Wave LED blinking slowly. Once the firmware update is completed, the Minitaur should reboot automatically. Your Minitaur is now updated with the new firmware.
Run the Minitaur Editor and check for the firmware version by clicking on “Settings”. It should say 2.1.21. If it says anything other than 2.1.21, it means that the beta firmware has not been updated successfully, and you should repeat the process again from the first step.
Restore settings to defaults by clicking on “Restore Default Global Settings” on the Editor’s Settings page.
Haven’t tested everything yet but I noticed something
The release button on the editor, which I hadn’t noticed before and it shows up only on the Panel window, does change when you press it on the hardware unit, but the physical button does not change when you do it from the editor, when the envelope is not in Linked Mode. When this function is active, the hardware does reflect what you do when you press the button on the editor.
I wonder if this the expected behavior, I am still unable to fully understand how these modes work and how to control the Release time from the hardware
There is something I still don’t know if should work like this: The envelope sustain doesn’t work if Ableton Live is synced externally and the clock is stopped. It does work while doing playback, as well as if the DAW is the master clock
I can’t get the Mac updater to work on my studio machine, it doesn’t recognize the Minitaur when it’s in bootloader mode (the device is recognized by the system, but the updater fails to find it).
This is what I did:
Powered up my Minitaur as usual (it’s connected through usb directly to my MacMini - no hubs in the middle)
Started the updater and waited for the Minitaur to be recognized
Once the Minitaur was recognized and the instructions appeared on the screen, I put the Minitaur in bootloader mode
I waited untill the updater ended it’s scan without finding the Minitaur.
[edit]the Minitaur stays in bootload mode, without the usual blinking associated with the firmware updating process[/edit]
I power cycled the Minitaur and repeated the whole procedure a few times with no luck, it’s still on v2.1.20 (and working fine).
I wonder if this may be a timeout at device scanning, since I have a lot of things connected to my Mac (2x microExpress, microLite, iConnect midi4+, Roland Studio Capture, Maschine Mikro, H9 and Timefactor). The updater also looks slow at finding the Minitaur at startup (by the way, my Mac is also slow at loading the midi setup at startup, if that’s of any indication)
Is there any additional test I should do, or should I update the Minitaur the old way with C6 and sysex files? I also have a Macbook without any other device connected to it, so I could try the updater on that machine…
Also, the “bootloader mode” instructions disappear from the updater window as soon as the Minitaur is powered off to put it bootloader mode. I think it would be useful to keep the instructions readable as long as the updating process starts, so the user doesn’t need to read them from somewhere else or remember the 2-3-4 steps by heart.
It’s possible that since your system is slow and loaded with many other USB devices, it takes some time for the updater to detect it. Are you connecting the minitaur through a USB hub ?
Please try to connect it directly, and have all other devices disconnected when attempting to update the firmware. Let me know if it makes any change.
As far as the second comment, I realized it too. Not sure we can change it, but I’ll check.
I am making some more tests, using Win7 up to now, and it looks like the MIDI Clock playback problem exists only when using Ableton Live
The Sub Phatty does behave as expected, so now I am considering it a bug on Minitaur’s firmware
The problem is the following:
If Live is being synced by an external MIDI Clock (and I have tried with at least two different ones), Minitaur’s Sustain stage on the envelopes does not work, while playback is stopped. It does work fine during playback.
During playback, the notes do trigger, and the rest of the envelope stages do work (I changed the Release time and it did), but whether I held the key or not, it jumps directly to the Release stage, without Sustain.
If Live plays back with its internal MIDI clock, the envelopes behave as expected, all the time.
This is happening with the editor closed as well. It does work as expected on Renoise and Bidule on the same computer. I haven’t tested it yet on the Mac Mini (El Capitan) at our showroom.
Now the Release on/off button on the hardware responds to the Editor the same way it does to being physically pressed… that is, you can toggle the Release On/Off button from the editor, while the Minitaur is in “independent decay/release” mode, and the hardware Release on/off state will also change. Please note however that this still causes no effect other than to change what will happen when you turn the “decay/release” knob on the hardware… if in “independent decay/release” mode, then the same knob will adjust Decay time when the Release button is dark, or Release time when the Release button is lit.
This is NOT a bug and is by design. When the hardware is not in “linked decay/release” mode, then the RELEASE button on the hardware is doing nothing to the sound. The only purpose of the RELEASE button (on the hardware) in this mode is to change the function of the hardware “Decay/Release” knob.
To be clear… this is when Ableton Live is not its own master clock, but rather the whole DAW is being slaved to some other clock source? (e.g. a hardware sequencer, or some other software is the master clock, and Live is synced to that other clock?)
When you say “jumps to Release stage” you mean that the Sustain is effectively at zero, and the sound always dies out even if a key is still held? does this happen for notes that are played after Live is stopped, or only notes which are held while Live is playing and then continue to be held when Live is stopped (i.e. stopping Live is stopping the held note)?
I find that “stopping Live stops a held note” regardless of whether Live is synced to some other clock or not, or whether Live is sending clock to Minitaur or not… checking in MIDI monitor I see that Live is outputting a Note Off when I stop its transport… the Minitaur is just responding correctly to the Note Off sent by Live. This happens even when I am still holding down a key on my controller keyboard; Live generates a Note Off itself when I stop its clock. Nothing I can do about that, if that’s the issue you are reporting.
Thanks Amos for making it work exactly as the hardware does!
Indeed, it is still confusing for me how to use it, especially when I want to set the Release time in a live situation, without the editor. I will try it tonight with this new description
Yes, this happens when the DAW is slaved to an external clock (tried with the OP-1 and an old QX5 plugged into a KA6).
Exactly, the Sustain is at zero even when a key is held. It does happen to new notes that are played when playback is stopped, unrelated to the Note Off command which every DAW sends when you press stop.
If there is no sequence sent to the Minitaur during playback, you can play it and it works fine. After the external clock stops, the problems comes back.
The problem does not exist when the DAW is Renoise or Bidule, on the same Windows 7 64-bit computer and the same hardware is used as external clock. The problem does not exist at all using the same computer, the same external clock sources and even using Live with the Sub Phatty.
Are you doing these tests on a mac? I am able to try it with the same software on OS X El Capitan if you need me to. I have the same DAWs as on Windows
My suspicion is that this might be related to Moog’s MIDI driver. Should I try uninstalling it? I understand this means I should uninstall the one for Minitaur, Sub Phatty and Sub 37
This is super weird. There is no association anywhere in the firmware between clock, and Sustain level, or clock and envelopes in any way. Yes I was testing on a Mac although I can test Windows also… and for any issue you encounter that does not involve the Minitaur Editor plugin, you can certainly test with the MIDI driver uninstalled. For Minitaur you should be using the latest Minitaur-only version… in theory you should be able to uninstall only the Minitaur driver and leave alone the drivers for Sub Phatty, Sub 37… but you can of course uninstall all, and re-install drivers after testing.
one thing to try is to route MIDI from Live through MIDI-Ox, via virtual MIDI cable, for monitoring… to see if any other messages are sent to the Minitaur in your test scenario, other than Clock/start/stop/MIDI notes.
I just checked again and I can confirm the problem is exactly the way I described it above.
I am running Live 9.7.1 64-bit, since MIDI Yoke is a 32 bit port, it doesn’t see it and I am unsure if MIDI-OX is able to communicate with a 64-bit virtual MIDI port
Of course I understand there is no relation between clock and envelopes, but as soon as I press the EXT button on Live, the problem arises, until I turn the function off, when it goes back to normal
Hopefully I will test all of this in the mac at our workshop tomorrow, and maybe as soon as tomorrow night uninstall the drivers on the Windows 7 to see if it is related
will install Live for Windows here (am running WIndows within Parallels on my Mac; hoping that makes no difference) and see if I find similar. Did not see any such issue when Live was synced to external clock (running, or not running) on Mac OS.
edit: does it make any difference what preset is active on the Minitaur, or is this behavior the same for any/all presets?
I just arrived at our workshop and plugged in my Minitaur to El Capitan; Live 9.7.1 64-bit and 32-bit gives exactly the same problem. If I press the EXT button on Live to listen to an external MIDI clock, the sustain disappears and it comes back as soon as I turn the function off.
But, I found something! The OP-1 may be the culprit. If I plug it out or turn it off, then the envelopes do trigger correctly. If I turn off the device as the external clock, they do work, whether the EXT button is lit on Live or not. Haven’t tested this in Windows yet, will try for sure tonight
Since the OP-1 has different firmware versions, I have yet to try those.
I opened Renoise and used it slaved to the OP-1 in El Capitan, and there wasn’t any problem at all with Minitaur’s envelopes
I wonder if anybody else is able to try this?
EDIT: Yes, it happens on every preset. I am currently making tests on different firmware versions of the OP-1
I just tried with several different firmware versions of the OP-1 and the problem is there, always. Only in Ableton Live, only with the Minitaur, both in mac an pc
EDIT: On mac I am able to use the software MIDI Monitor, and the activity shown, besides the notes sent to the Minitaur, are only MIDI Clock messages. I don’t see Active Sense, Sysex, invalid nor any other strange activity
I have been testing this on all kinds of possible scenarios, including Snow Leopard (Live 9.1.10) and other synths.
There was one mistake I made, and it seems that at least all Moog synths have the envelope problem when Live is being synced to an external MIDI Clock and playback is stopped.
OP-1 is unrelated. If the device which sends MIDI Clock signal stops doing it, the envelopes of Sub Phatty, Minitaur and Slim Phatty trigger correctly. If there is an external MIDI Clock and Live is set as slave, the envelopes do not trigger correctly when playback is stopped.
The problem only exists in Ableton Live (all versions, all platforms) and it does not arise in any other DAW I use; Renoise and Bidule. I did not test it on FL Studio and I do not have a Cubase, Logic or ProTools license. The problem is Ableton Live, not Minitaur nor anything else. Sorry for all the hassle!
It would be great anyway if someone is able to reproduce it, maybe we can find what is the problem, or maybe speak to Ableton about it
Besides that, I found something on this firmware which doesn’t seem to work, though I’m unsure if it is already reported:
If the LFO is set to MIDI clock sync, it doesn’t work until it receives a MIDI Clock Start message. This only happens when you use the unit outside a standard DAW, for example MIDI-OX or MIDI Pathcbay, and you are using an external sequencer.
I know this is a very specific use and a minor bug, but I’d like to point it out. In case it is confirmed it can be included in the known bugs section
