T3 v112 beta firmware, if you care to try it out

Hi all,

I’m hoping some of you would care to try v1.12 firmware on your Tauri.
There is little/no risk associated; if anything seems wonky you can hold the CUTOFF + SELECT LEVEL buttons while turning on the power and boot to “safe mode.” You can always play in Safe Mode or use it to load different firmware.

Here are the new changes in v1.12:

  • Added time-out for LFO MIDI Sync; if clock is lost, LFO will revert to internal clock.
  • Fixed bug when changing from LFO Midi Sync back to Internal sync and could not adjust LFO internal Rate.
  • When set to Internal clock, LFO Rate now displays in Hz and Arp Rate displays BPM.
  • Can adjust Arp internal clock in increments of 0.1 BPM from the Advanced Preset menu.
  • Fixed Advanced Preset menu: Note Latch On/Off. (did not work in v1.11)
  • OscB Freq and Beat now display parameter range -2048 to +2047; 0 = no detuning relative to Osc A.

NOTE This is a beta version so there is some debug code you might possibly encounter. If you see an error code appear on the LCD when you first turn on the unit after the power’s been off, please let me know about it. This is totally harmless and you can exit out of the error screen by pressing MASTER+PRESET. I’m just testing some stuff, and the more units we can test it on the better. So, your help would be greatly appreciated.

All that said, this should be the most stable and polished version to date… but I won’t know until we’ve tried it. Download the update pack here:

v1.12WIP - beta release for Windows

v1.12WIP - beta release for Macintosh

Thanks for checkin’ it out!

-Amos

A couple of notes about the Arpeggiator internal clock, now that it displays BPM:

The range is 20 to 620 BPM. This is measured as one arp note = one quarter note. So, 120 BPM is quarter notes at 120 BPM; if you want the arp to play eighth notes at 120 BPM, you need to set the Arp Rate to 240 BPM. Sixteenth notes = 480 BPM, and so on for other tempi and time signatures.

If you’re not syncing to MIDI clock, I say just set it by ear (or by tap-tempo) and don’t worry about it. On that note we’re planning some improvements to tap tempo in the future; probably averaging and a selectable tap-rate multiplier.

I measured the internal clock as pretty accurate to the stated BPM, but I imagine it will drift relative to another free-running machine clock.
If you are trying to dial in a specific BPM using the internal Arp clock, here’s how:

Set wide changes in range using the control wheel. Set Lower Select Level [amber], press Arp RUN and LATCH buttons at the same time to map the control wheel to Arp Rate. The display will show you whole-numbered BPM.
Due to the resolution of the control wheel, you’re actually setting fractional BPM but I didn’t have enough characters to display the tenths digit here.

To set the Arp BPM accurate to 0.1 BPM, go to Advanced Preset->Arp Rate and you can use the value knob to dial in a precise BPM in the range 20.0 to 620.0. You can use the Control Wheel in combination with the Advanced Preset->Arp Rate menu to set a precise BPM quickly.


Let me know how this works out for you.

Thanks,

Amos

i’ll test it right away if you send me my Taurus :smiley: good luck with the update!!

I’ll run 'er through the wringer tomorrow. I’ve been enjoying the first update so much that I didn’t even notice any of the minor issues you mentioned! Amos - thanks again for adding my “hold patch change” feature request, it is very much appreciated.

I tried it…and I love it! :smiley:

Amos, this version did not work for me! Loading of new FW & presets showed succesful, but after playing through a few presets, I noticed many notes where the oscillators were horribly out of tune with each other.
I figured it was simply a bug & that I needed to do a note calibration, so I did - the calibration never made it past the first note, and just sat there “hunting” for the frequency, and I cancelled it after an hour of waiting (previous calibrations took less than 15 mins. to complete).
I re-loaded the FW, & the issue did not go away. I’ve previously completed a note calibration (before this update) with success, and I wonder if this had anything to do with the new version not “taking”. I have now reverted to V. 1.11, and the tuning issues have disappeared.

Hmm, that’s very interesting. :frowning:

First of all, here’s today’s build, which I’m calling Release Candidate 1.
The MIDI time-out code needed a small tweak and works great now,
(you can pull the MIDI plug while synced to clock and it will switch automatically to internal clock)
… and I turned off the error-message reporting that I was testing in the last build.

Taurus 3 v1.12 RC1 for Mac
Taurus 3 v1.12 RC1 for Windows

Now about the tuning. It’s possible the tuning table got corrupted or isn’t being read correctly in the new firmware, although I haven’t seen that here.
Couple of things for you to check if you’re game (after loading this latest version, of course):

  1. Do you still have the same problem right off the bat?
  2. if you power down after doing the update and turn the Taurus back on, do you still have the same tuning issues?
  3. if all of the above, do a Note Calibration but change the starting note to something higher, like 6 or 8… does this work? Sometimes the very lowest note is the most difficult for it to dial in. If this does work, is the tuning OK on all notes afterward?

Thanks for testing and reporting back on this… it’s a huge help. I had a unit here that had really bizarre tuning issue right after a fw update, but a successful note cal afterwards fixed it. It turned out to be a bad value in one of the tuning lookup tables, which was fixed by a good note cal.

Soo… thanks for being adventurous with this… and let me know how it goes the next time you have a chance to test the above. :slight_smile:

Cheers!

-Amos

Loaded the latest version & initally had the same issues as before - bizarre tuning issues, inability to complete a correct tuning calibration, etc., but this time, I did a Master Reboot after the load, and the tuning & calibration issues went away after a successful tuning calibration.
So far, no bugs to report, but two things are worth noting; when updating the FW, my machine needs to be powered off/on to get past the “pages loading” screen & complete the update, and when pressing the reboot button, nothing appears to happen until you actually power down & back up again.

Oops - spoke too soon. Each time I power it off, the tuning wierdness returns, & I have to reboot each time when I turn it back on. Is it possible the tuning LUT is corrupt in the new FW? btw Amos, do you want me to post my findings here, or would you prefer I PM them to you?

well, I don’t mind it getting posted here… although I don’t want other folks to get scared off, necessarily. Other Folks, keep in mind this is beta firmware we’re talking about here. Whatever’s going on, we will get it dialed in correctly before the next official firmware release.

I have not seen this behavior you’re describing until now. A question: Each time you power down and power back up you have a funny tuning issue. If you do a successful note cal the tuning is OK until you power down again.

What happens if you do a successful note cal, then instead of turning off the power you do a Master Reboot from the system utilities menu? Same problem, or is the tuning still OK after a warm boot?

Verrrry interesting…

My thoughts exactly, and I have complete confidence that the official firmware will be dialed in.
I test because I enjoy helping & being part of the process, because I have complete confidence in you and Moog, and mainly, because its fun!
I work this weekend, but I’ll do more testing Monday & let you know what I find.

Hmm…I did not have any of the issues superd2112 speaks of. :confused: What I did discover was the analog-ness of the wheels that wasn’t there before. Stepping was no longer an issue with the volume wheel, and the control wheel is much smoother as well. Also, as much as I tried, I could not get any stuck notes. The arpeggiator also seems a bit smoother, and it’s not as difficult to keep the beat…though that just may be my playing ability getting better…I dunno. I do like the BPM selector changes…that makes life a LOT easier! :smiley:

No problems over here.

I’m synching the T3 to a Roland RC-50. It’s working good.

Is there any way to have the T3 start and stop with the RC-50? I guess the T3 would need to be able to understand MIDI Start and Stop messages.

This is good news - this is going to be my set-up (well I’m halfway there with the RC-50). I may be asking you for tips in the future. :mrgreen: And yes I want to sync T3 arps with RC-50 loops (which is what I assume you’re trying to do).

Amos, regarding the “warm boot” procedure - whenever I try a reboot, the display freezes on the reboot screen, and the only way to get out of it is to power the unit off & then back on. Is this normal? I never tried the reboot function before updating the firmware, so I don’t know if this how its supposed to work.

nope, definitely not normal. That is a restart-related bug. Normally a restart will take you all the way through the normal startup sequence and back into performance mode. We’ll look into this more closely here and see what we can find.

This is good news - this is going to be my set-up (well I’m halfway there with the RC-50). I may be asking you for tips in the future. Mr. Green And yes I want to sync T3 arps with RC-50 loops (which is what I assume you’re trying to do).

Just started trying this yesterday. It is working. But I’m only at step one. I plugged a MIDI cable between the two units. I was able to control the tempo of the T3 arps with the RC-50. :smiley:

Amos, any news on the (or is it just my) restart bug, and how soon until the next fw update?
Thanks, Rich.

Thought I might add, I had some strange behaviour tonight with the transpose.

Can’t remember the exact circumstances, but transpose would stick in one key, pressing another pedal (with the transpose LED flashing) changed the pitch slightly but not as much as it should have done. Releasing the pedal reverted to the original pitch.

Cured by a restart, and only happened once, but there you go.

Just discovered an anomaly - when the arp is running, if I attempt to adjust the filter cutoff, the whole pattern jumps up an octave for a split-second, & then returns to normal. Definitely not a filter resonance spike, it is an octave jump. Master restart has no effect, but then again, my machine currently has a restart bug.