MidiGAL -- yet another MIDIpal inspired project
  • MidiGAL is a simple Atmega328p based MIDI controller board featuring 8×2 LCD, MIDI IN/OUT connectors with LEDs, one encoder and one switch. It can run a bunch of different firmware variants (updatable via Sysex), including original unmodified MIDIpal firmware.

    One cool firmware available for MidiGAL is MidiClk — high precision Midi Clock Tester/Generator that is capable of straightening up your DAW or iOS MIDI Clock. See more details here .

  • Cute !

  • my first impulse was: great idea to replace that clickable encoder with a regular encoder plus tact switch! one of the few things i don’t like about my midipals is how i keep accidentally clicking the encoder. but then i saw that the midigal bom also requires a clickable encoder. so now i’m confused: doesn’t the tact switch replace the encoder switch? what is it for, then?

  • Original MIDIpal firmware has no idea the switch exists, so it cannot do anything with it. One can easily modify MIDIpal firmware so that switch acts the same way as encoder click though.

    MidiClk firmware uses switch to clear starts in MIDI Clock Tester mode and to start/stop clock when in clock generator mode.

  • Nice! The MidiClk firmware should also run on the MidiBud, right?

  • Yup… MidiGAL’s switch is equivalent to the rightmost switch on MidiBUD.

  • Does this mean MidiGAL replaces MidiBUD in your product portfolio ?

  • Yeah, at least for now. MidiBUD was originally devised as MIDI Project Breadboard Friend, but most people use it to run MIDIpal firmware. MidiGAL is a better alternative because it can be easily encased.

    I may still come up with MidiBUD Mk2 — functionally the same as the original MidiBUD, but with components and UI parts on different sides of the PCB. However, every time I start thinking in this direction, I end up with MidiREX PCB — adding LEDs, strat/stop/run switches, super fast static RAM instead of terribly slow EEPROM etc.

  • BTW, below is a “work in progress” description of MidiBUD firmware that me and a bunch of early adopters find to be very useful when you put it between your controller keyboard and the rest of your rig. Currently it runs on MidiBUD hardware, and it is a good candidate for MidiBUD Mk2, however it could be easily ported to MidiREX hardware and be even more useful.


    MidiBUD is a 4 channel MIDI processor, which forwards MIDI IN events to up to four MIDI OUT channels. MIDI events can be forwarded as is or transformed. The set of parameters that defines transformations is called a “scene”.

    So MidiBUD has 4 scenes. If a scene is selected, MIDI events processed by this scene are sent to MIDI OUT. When you press scene buttons 1-4, you select the corresponding scenes 1-4. You can select more than one scene at the same time by pressing several scene buttons simultaneously. Or you can add/remove scenes without unselecting other scenes by holding down SHIFT button (the rightmost fifth button) and pressing the appropriate scene button.

    Scene parameters:

    Scene output channel: none, 1-16 … if set to ‘none’, midi events are forwarded on the same channel they were received, otherwise they are forwarded on the selected channel. Using this setting you can quickly switch between 4 sound modules connected to MidiBUD output. Or layer sounds of those sound modules if you select more than one scene simultaneously.

    Scene key hold: if ‘on’, the sound will continue when you release a key until you release all keys and press new ones. So you can have that “Shine on your crazy diamond” Gm strings chord playing for two and half minutes while you playing solo notes on your favorite analogue mono synth.

    Scene transpose: -48 … +48 semitones, allows you to transpose scene notes up/down for up to 4 octaves… good for layering. I.e. the Gm mentioned above won’t sound right if you don’t mix in some Hammond sound two octaves below.

    Scene zone: specifies keys zone – midi note events will only be forwarded if they are within zone. Useful when you need to play more than one sound module at the same time using different parts of your keyboard. Again, that Gm above needs a low bass note mixed in to sound authentically.

    Scene velocity: specifies scene velocity curve (none, soft1,2,3, hard 1,2,3, wide 1,2 or constant)

    Scene after touch: specifies scene after touch curve (none, soft1,2,3, hard 1,2,3, wide 1,2 or constant)

    Scene filters: specifies scene filters, you can filter out program change, control change, after touch or pitch bend events

    Scene program: specifies bank/program that will be sent to MIDI OUT when the scene slot is loaded.

    Scene root note: specifies scene root note (used by scale constrainer)

    Scene scale: specifies the scale to constrain notes to, the out of scale notes will be converted to the closest scale note

    Finally, a set of 4 scenes may be saved into a “slot” and re-called later. Slots have 12 character names for easy identification and numbers from 0 – 99, so there is 100 slots available.

    The project is still in development: the above functionality is fully implemented and tested.


    Let me know if you have MidiBUD and want to try this firmware.

  • Is this also the [TBD] firmware in the MidiGal page?

  • Nope, the thing above absolutely needs 5 switches, and MidiGAL has only one switch.

    The [TBD] firmware for MidiGAL that is close to being published is MidiArp — an advanced arpeggiator with a few twists… it’s a little too early to discuss here.

  • “In MIDI Clock Generator mode, MidiClk generates super stable MIDI clock with BPM selected by the encoder, or measured by sampling MIDI Clock events received on MIDI IN.”

    Does this work as a tap tempo feature? Or is there a way to set tap tempo on the Midigal buttons?

  • Sticking a few pots on the board would be nice. Might be next best thing to the mythical Octopot :)

  • @bonobo — at this point MidiClk does not have tap tempo feature. I’d love to have one but don’t see any reasonable way to expose it in the UI: the switch starts/stops, encoder click activates/deactivates tempo selection mode. So you have to explicitly select tempo with the encoder or feed it in from your DAW.

  • Ok gotcha. Still will probably end up getting this and putting it in a case.

    @kvitekp – that midibud firmware looks incredibly useful and I’d love to try it out. I have a midibud already as well.

  • MidiBUD firmware v0.93 is available here .

    If you’re using MidiBUD with MIDIpal firmware, just send midibud_pal.syx to its MIDI IN after powering it up while holding down the encoder.

  • Ordering this asap. The clock tester is very, very interesting.

  • i cant get this new firmware to work on my midibud when i upload to midibud i just get a blank screen?

  • @martindunne — how exactly are you uploading it?

  • midi with c6, i have done all other projects the same way, it looks like it is uploading, the midi in light flashes but when it is completed i get nothing. also the midibud.sysex i get no upload lights and had to resort to loading the hex file with isp programmer

  • midibud.syx won’t work if you MCU was flashed with MIDIpal bootloader, you need to use midibud_pal.syx in this case. However, if you flashed the .hex with ISP programmed, bootloader was erased.

    Try to reset the device by powering it up with switches 1, 3 and 5 pressed down.

  • i loaded the hex and muboot . will give reset a try

  • you may want to try loading midibud.hex only… loading both bootloader and main firmware manually may be tricky.

  • I really love the tester mode; below you’ll find 120 BPM results from the MPC 1000 which scores a disappointingly 2.4% and Ableton Live running on OS X using an ESI MIDIMATE II “cable style” interface which scores a reasonably decent 0.4%. Can’t wait to test my other gear! ;)

    1224 x 1632 - 510K
    1632 x 1224 - 413K
  • Ableton Live running on OS X is really impressive at 0.4% !

    BTW, double clicking the encoder in MIDI Clock Tester mode will toggle “max” versus “current” standard deviation mode. This is helpful when you want to test MIDI Clock source over time because it will display the worst sdev over the entire observation period.

  • @t2k — is your MPC 1000 running jjos or original firmware?

  • @kvitekp My MPC 1000 is running JJOS2XL 3.47. It’s even worse when you use “max” mode:

    640 x 480 - 61K
  • Hmm… looks a bit disappointing. At least it’s accurate at 120.0 BPM so you can “repair” clock for chained devices using Midi Clock generator mode.

  • Some more results; the Elektron RYTM and Analog Four both score about 1.4% at 120 BPM in Max Mode. When the clock in measured through the Faderfox PC4 pot controller, it goes up to 2% when you generate a lot of CC messages by tweaking the pots on the PC4.

    All of these results are a bit disappointing, to be honest.

    640 x 480 - 106K
    640 x 480 - 118K
    640 x 480 - 76K
  • @kvitekp I might do a bit more testing to see if fixing the clock with MidiGAL makes any difference. I have a suspicion that it’s not going to improve much since all the slave devices I use already average MIDI Clock instead of slaving to it “directly” like older devices used to do.

  • While working on MidiClk firmware I hooked it up to my beloved Moog Sub37 (firmware v1.0.7) and was shocked to see its output MIDI Clock jitter at about 2% which jumped up to 5-6% when I used any of the panel controls… imagine the sequence running and you do that ubiquitous filter sweep ruining your clock.

    Amos reacted quickly and greatly improved stability — it’s ~0.2% in v1.0.13 … however, it still degrades down to 2-3% when panel controls are used :(

  • @t2k — even if the slave devices average incoming BPM, they will still benefit from receiving coherent stable clock.

    I’m working on advanced arpeggiator firmware for MidiGAL (which is called MidiArp btw) and while I was playing with Swing setting which can be regulated at 0.1% increments (with 100% being an 8th note) I found that I can clearly feel groove that appears at 50.1% setting (which is minimal forward swing setting in MidiArp). However, I can only feel it if the original clock is super stable… any jitter kills the groove immediately. Which is not surprising since numerically, 50.1% swing is measured by MidiClk as 0.198% standard deviation, so 0.2% is enough to mess it up.

    Subinterger swing settings feel soooo nice, it’s the whole new world for me!

  • When I start generating a lot of aftertouch messages on the RYTM, I can get the jitter over 2.1% as well. :/

  • Just for fun, I just tested the USB MIDI output from the RYTM as well using an MIDI USB host box (Kenton MkII). This results in the exact same amount of jitter as when using the DIN MIDI out on the RYTM.

    Interestingly, it does jump up to 6% once you start adding aftertouch messages, but I guess that kinda makes sense since USB MIDI does have higher bandwidth.

    Still, to me it seems more sensible to prioritize clock messages over pretty much any other type of MIDI message, but maybe I’m missing something.

  • @kvitekp Would you mind sharing how you communicated your findings to Moog? I’m trying to figure out the best wat to communicate these results to Elektron so that they’re most likely to improve things.

  • Here’s another result from Ableton Live running on OS X, this time using a Behringer UMC204 as the MIDI interface. Still at a reasonable 0.48%.

    640 x 480 - 77K
  • Is the MIDI interface the only thing you have connected to the USB port? Would be interesting to see how it performes with an audio interface connected to the same USB port while recording (several channels) audio.

  • It’s only a two-channel in, four channel out interface. I would be surprised if that would make any difference.

  • It’s kind of funny, because so many people complaining about the bad MIDI timing of Ableton Live.

  • It is. I was not expecting these results. I might instal the official Akai OS on the MPC to give it a try.

  • In slightly unrelated news; the Micro Q has an option to send MIDI Clock that simply does not work.

  • @t2k — I just made a comment on Moog Sub Phatty forum where some real musician complained that Sub37 clock deviates from his mechanical metronome. In a few hours I got an email from Amos (the firmware guru at Moog) with a beta firmware attached which greatly improved clock jitter.

  • @kvitekp Thanks, that’s a very rapid response; takes me one step closer to getting a Sub37 myself one day. :)

    I posted a message about the clock jitter from the Analog devices on the Elektron forums

  • Here are the result from Akai’s original firmware, as well as various versions of JJOS:

    JJOS1 V4.99L: 4.1%
    JJOS2XL V3.47: 3.2%
    JJOS3 V1.29: 3.1%
    Original Akai OS V2.13: 3%

    640 x 480 - 71K
    640 x 480 - 68K
    640 x 480 - 69K
    640 x 480 - 74K
  • And finally the OP-1 going through the Kenton MIDI USB Host MkII scoring an equally disappointing 3.3%. Please note that this result might be worse because of the MIDI USB Host.

    640 x 480 - 104K
  • @t2k — looks pretty disappointing… could you please try MIDIpal clock?

  • @kvitekp Sorry, I don’t own a MIDIpal. My first reaction after seeing the MPC results was that I must have made an assembly mistake putting together the MidiGAL. Are you thinking the same thing based on these results?

  • @kvitekp Thought I’d also try with NordBeat2 for comparison, but I’m strangely enough getting much better results at 0.3% (you got 1%)…

    This is on an iPad Mini 2 running iOS 8.1.3 with the Behringer UMC204.

    446 x 640 - 98K
  • @t2k — do you have MidiALF, MidiREX or MidiBUD? While I cannot imagine assembly mistake that would cause this kind of results, it would still be good to establish a baseline.

  • @kvitekp No. I’ll DM you.

  • Just saw this thread. Excellent stuff!

  • Seems like there are also 8x2 OLED’s#

  • Above, @kvitekp remarks that “even if the slave devices average incoming BPM, they will still benefit from receiving coherent stable clock”.

    I’ve found that this is currently not always the case, or at least not in my situation when the A4 is slaved to the RYTM. Using MidiClk in Clock Generator mode in between the RYTM and the A4 results in playback that’s noticeable out-of-sync and sometimes jittery, especially when playback is stopped and continued. As far as I’ve been able to figure out, there seem to be two reasons for this:

    1.When MidiClk is in Clock Generator mode, it stops sending out MIDI Clock messages after it receives a MIDI Stop message. This is in contrast to the behavior of the RYTM which always sends out clock messages, regardless of its sequencer play state. This means that there’s no way for the A4 to reliably sync to the correct tempo by averaging clock messages before playback has been started.

    2. When you hit the “Play” button on the RYTM, it immediately sends out a Midi Start or Continue message followed by a clock message, essentially “resetting” the stream of clock messages it is sending out. The averaging done by MidiClk “fixes” this which can result in the A4 starting a little behind the RYTM.

    Please note that I’m not saying MidiClk is doing anything wrong here, it’s just that in this specific case, it’s making things worse instead of better. ;)

    For more reading on syncing with MIDI Clock, please see here

  • @kvitekp: I would like to test the MidiClk firmware with my MidiBud. Is there a .hex or .syx file to download?

  • @cj55 — MidiClk v0.92 is here .

    Chances are your MidiBUD has MIDIpal compatible bootloader, so you’ll have to use midiclk_pal.syx file.

  • @t2k — I was testing MidiClk with clock sources that don’t send MIDI Clock messages while stopped, so it restarts outgoing clock sequence when it receives Start… probably I should change logic so that MidiClk Generator will always send output clock if it receives one. I believe my Korg Z1 always sends output clock when it’s enabled and sends Start/Stop when ARP is activated, so i’ll be able to create setup similar to yours.

  • @t2k — please try MidiClk v0.93 — this version always sends MIDI clock so that slave devices can average it before receiving Start event.

  • @kvitekp I think there are two changes that might make sense:

    1. Always send MIDI Clock messages regardless of the playback state of the master device.

    Even though this is not required according to the MIDI specifications, it is also valid behavior and has the benefit of allowing slave devices to set tempo before playback is started and of allowing slave devices to continue to sync after playback is stopped which can help with tempo-based effects such as delay. I can’t think of a device or situation where always sending clock would be a problem, but maybe I’m overlooking something.

    2. Disregard the time interval between two subsequent MIDI Clock messages when a MIDI Start or MIDI Continue message is sent in between those messages. This makes sure that there’s no negative impact on the tempo detection for master devices that “resets” clock when the play button is pressed.

    Please note that you probably only want to do this when playback has previously been stopped since according to the MIDI specifications, a slave should ignore MIDI Start or MIDI Continue messages during playback.

  • @kvitekp Oops, sorry. Just noticed that you already implemented 1. while I was typing my comment… :) I’ll give v0.93 a try tonight.

  • @kvitekp Sorry, I had an extremely busy week this week; I’ve only found time to test v0.93 just now.

    Tempo is now detected on the slave device before playback is started, but the A4 (slave) can still end up starting out of sync, especially when playback is toggled rapidly. I think this is because what I describe under 2 in the messages above.

  • Hey there,
    Here are the results with the Korg electribe2:
    Oh well. I hope to test more gear in the future.
    Thanks again to kvitekp for the MidiGAL. ;^)

  • Here is another project that runs on MidiGAL hardware: MidiArp, an advanced MIDI arpeggiator module that has all standard and a few unique features, such as very musical latch mode, super stable internal clock, nice swing and two modulation sources with velocity, after touch and CC destinations.

    With these additions what started as a pretty ordinary arp implementation turned out to be a very useful instrument, equally suitable both for studio work and live performances.

    Please check it out here.

  • @kvitekp: would be cool to see (or hear the demo) very intriguing feature set, kudos!

  • @ilya — i’m going to record some this week.

  • I know I’m late to the party, but can the new Midi Bud firmware be updated via SYSEX, or do I need to use an AVR ISP?

    I mostly use mine in dispatch mode or as MIDI CC and aftertouch filter.
    Would it also be possible to have an added “layer” parameter in dispatch mode that would send the first note to both channel 1 and 9 , the second to 2 and 10, and so on? That way I can layer up 16 single osc synths into 8 two osc synth voices.

    That is pretty much just a special use case for the Electribe 2 whose pad midi channels can not be changed on the device.

  • Yeah, the MidiBUD firmware v0.93 here has .hex and .syx variants. Note that if your device has MIDIpal compatibly loader, you’ll need to use midibud_pal.syx to update it.

    “layer” parameter you’re suggesting does not seem to fit in what MidiBUD is doing, and MIDIpal covers that area perfectly.

  • You are right. I forgot that MidiBUD and midiPal firmwares are totally separate entities. I am currently running midiPal 1.3 on my MidiBUD. I will be sure to check out the latest midiBUD firmware as it sounds very useful.
    The clear answer is to have two MidiBUDs. :)

  • I recommend to get MidiGAL with MIDIpal firmware v1.4 and use your existing MidiBUD to run MidiBUD firmware.

  • I asked in the midisizer.com comments, but I figured I would ask here as well. I can’t seem upload new firmware via sysex. My device has the initial MidiCLK firmware. I hold down the encoder and turn it on to put it into firmware upload mode. Then I send the sysex and see the MIDI IN light turn off, but it doesn’t blink for each received packet like I am expecting. Once the sysex send is finished, the midigal doesn’t reboot into the new firmware. I have tried this with these interfaces:

    M-Audio Uno
    Alesis Q25
    Akai MPK49
    iConnectivity MIDI2+

    I know that at least a few of those interfaces have a history of not working well with sysex. I also have an Arduino sitting here that I could use ArduinoISP with to program the MCU directly, but I haven’t done this before and I would rather use sysex if at all possible. FWIW I have tried this with both the midiarp, midiarp_pal, and original midipal firmwares. Same story with all of them.

  • @hashbang Please try with Elektron’s C6 adding a delay of at least 250ms between each packet sent.

  • @t2k thanks for the reply. I should have mentioned in my first post, this was all done using the C6 tool with the recommended 250ms delay. I’ve also tried with higher delays (500ms, 1s). I’ve tried with Midi-OX as well, no difference.

  • M-Audio Uno works perfectly here… however, this is a 10 year old one, the rumor has it that the newer models have problems with bulky sysex data.

    Are you sure that MidiGAL enters firmware update mode? it should blink both LEDs interchangeably.

  • New MidiClk firmware v0.96 is released. It adds Hold Mode (similar to MIDIpal’s Sync Latch app) and has greatly improved master clock tracking, which fixes problems with MIDI Clock sources that don’t send clock events when stopped earlier firmware versions had.

  • I meant to update sooner, but I was able to flash new firmware onto my MidiGAL(s). I ended up just using an arduino as an ISP programmer, and it worked with no problems. Thanks for the help!

  • Did some MIDI Clock testing on my Amiga 1200 today. OctaMED Pro 5.00c scores about 0.3% but runs at 119.9 BPM when it’s set it to 120 BPM. Music-X 1.1 scores a whoppingly bad 9% and runs at 120.8 BPM when set to 120 BPM. Bars & Pipes Professional scores 2.5% and runs at 118.9 BPM when set to 120 BPM.

    Please note that I didn’t bother finding the most recent versions of these applications. I might try to get hold of them and run these tests again some day. Also, if anyone feels like sending me an Atari ST for testing… ;)

    To summarize, on the Amiga, OctaMED does pretty well while Music-X and Bars & Pipes are really, really bad at outputting stable MIDI clock. What’s interesting is that OctaMED has about the same level of clock jitter as Ableton Live on OS X.

  • Updated MidiClk firmware to 0.97 . It adds Sync24 output with two extra pulses: step and step count, both selected in the UI.

    562 x 368 - 69K
  • I got the same results as @foksadure above running the clock tester on the new Electribe. Here are my results so far testing at 120BPM in “max mode”:

    Ableton Live, OS X, ESI MIDIMATE II: 0.4%
    Ableton Live, OS X, Behringer UMC204: 0.5%
    Elektron Analog RYTM: 1.4%
    Elektron Analog Four: 1.4%
    Korg Electribe2: 1.8%
    MPC 1000, Original Akai OS V2.13: 3%
    MPC 1000, JJOS3 V1.29: 3.1%
    MPC 1000, JJOS2XL V3.47: 3.2%
    Teenage Engineering OP-1, Kenton MIDI USB Host MkII: 3.3%
    MPC 1000, JJOS1 V4.99L: 4.1%

  • @kvitekp Here’s the result of testing my build with yours. It seems fine, so I do think it’s safe to assume the above results are valid.

    640 x 392 - 79K
  • I wonder if there is a difference between those devices clock deviations in regularity. If the they are random or if they are somehow regular and this way creating a groove. Would there be a way to measure that?

  • @shiftr Yes, but it would take more sense to use an algorithm running on a desktop computer for pattern detection. You’d still use a device like this for reliable sampling and then send your data over for analysis.

    I would however be very surprised if you’d find any kind of meaningful pattern. :)

  • @shiftr — i could not detect any pattern with the devices i tested (HR16,SR16, ER1, RM1X,MC50MkII) using industry standard testing equipment, all the devices seem to have normal distribution:

  • The fact that the distribution of samples is normal doesn’t imply that there is no pattern (it’s just a very bad smell…). To be really sure that there’s nothing, you could also plot the autocorrelation function.

  • True… i’m no saying there are no patterns, i just could not detect any other peaks other than more or less normal distribution. i guess i could export data and try Excel’s or Python auto correlation functions… don’t have mathlab installed.

  • > t2k May 28
    > I got the same results as @foksadure above running the clock tester on the new Electribe.

    Thanks for the confirmation of the kinda sloppy e2 MIDI clock (still a fun device nevertheless).

    Try testing @25, 50, 100 and 125BPM for a little suprise. :)

  • Received a Yamaha QY70 a few days ago. It scores an impressive 0.1%. That’s more like it!

    530 x 640 - 131K
  • Yamaha has a proven history of great clock sources:

    2304 x 1536 - 459K
  • Damn. I sold my RM1x years ago. Regretted it almost immediately. Will need to get it back.

  • The QY70 is surprisingly fun by the way. I got it to sequence external gear, but it turns out to include a more than decent sounding rompler synth engine.

  • I think the QY70 has the same synth engine as my old TG300 module.

    I really loved that box, back in the day.

    In retrospect, it’s not the greatest-sounding synth out there, but it’s what I could afford at the time (1994), and it was more flexible than you might think.


  • I’d be curious to see the results of MidiClk with an Anushri and a Sonic Potions LXR...

  • and a midibox SEQV4 :D

  • FWIW; the one that kvitekp assembled for me is for sale. DM me in case you’re interested.

  • Aren’t the QY series the cutest thing ever? I have three! I really need to stop buying every midi box I see, these MIDIGals looks so sweet .. must resist.

  • hi
    i would know if this used as master midi clock,
    could send also clock for modular in paralel with the midi one?
    would use it as a clock generator/distributor for my setup.

  • @midirobot — yeah, in addition to MIDI OUT, MidiClk has 4 digital outputs, two of which output standard Sync24 signals (24PPQN clock and Start/Stop), and the other two are configured as following:

    pin4 outputs pulses with the period selected by the “StepLength” page which could be set to 1/64 triplet, 1/32 triplet, 1/32 note, 1/16 triplet, 1/16 note, etc. all the way to 2 whole notes.

    pin5 outputs pulses with the period selected by the “StepNumber” page which could be set to any value between 1 and 96, giving you a multiple of the period set by “StepLength” page.

    For example, if step length is set it 1/4 note and step number to 4, pin4 will give you quarter notes, and pin5 will have bars.

    Picture below shows pins 4 and 5 with Step Length set to 1/64, Step Number set to 4, running at 250 BPM with 1ms pulse width:

  • great!
    thanks for the detailled explanation:)
    so if i get it right no need hardware mods or firmware tweaks
    to get it working as master clock for midi and modular at same time.
    another question:
    the midi clocks stops when you press stop?
    ask this cause my octatrack and renoise are sending continious midi clock tick
    even the sequencer stopped…a bit annonying.

  • > so if i get it right no need hardware mods or firmware tweaks
    i recommend adding 1K protection resistors between MCU pins and output jacks.

    >the midi clocks stops when you press stop?
    no, midi clock keeps going… this is the only way slave devices can start on the correct clock tick. I can probably make it configurable at some point.

  • cool,nothing big to mods,
    about the clock should be awesome to be able to choose
    as an option continious midi clock tick or not.
    anyway will come to you soon to order a board :)

  • Quick MidiClk results with my newly bought MidiGal from t2K :
    A disapointing <1.56% @120bpm with Sonic Potions LXR
    An impressive <0.101% @120bpm with Korg microSAMPLER
    FL Studio 11/2 and Live 9 with Windows 8 and M-Audio Fast Track Ultra gives an unstable 120.1 to 120.5bpm…

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion