The extra buttons are used to select the track group directly, and the 4 integrated LEDs display the currently selected group. These buttons/LEDs are strongly recommented for new frontpanel designs.
It depends on your HW configuration, if an additional 74HC595 is required. I added it to the end of the BLM chain
The debouncing method I used for the BLM module is very expensive (RAM and CPU wise). MBSEQ V3 has no additional RAM free for such features (only if you would get rid of useful features like Undo buffer and Mixer…)
But I could add a “cheap” version which disables all BLM buttons for a short moment (e.g. 20 mS). I guess that you wouldn’t really notice a difference, because it’s the same approach which MIOS uses to optionally debounce normal DINs, and nobody ever complained about this
But I could add a “cheap” version which disables all BLM buttons for a short moment (e.g. 20 mS). I guess that you wouldn’t really notice a difference, because it’s the same approach which MIOS uses to optionally debounce normal DINs, and nobody ever complained about this
Exactly. I have a few commercial synths that do the same. I’d say go for it
The extra buttons are used to select the track group directly, and the 4 integrated LEDs display the currently selected group. These buttons/LEDs are strongly recommented for new frontpanel designs.
ah ok, it sounds like if building a new seq, these should be on the main panel, and only users with existing v2 seq would
want to put them on the extension.
It depends on your HW configuration, if an additional 74HC595 is required. I added it to the end of the BLM chain
just to be clear why i asked this: i am planning to build an extension module and connect it to the main seq with say a db9 connector, carrying only the din/dout signals. sounds like if other folks follow this and want the track group buttons on the extension (i think only makes sense for existing v2 seq), they will need to add these…
The debouncing method I used for the BLM module is very expensive (RAM and CPU wise). MBSEQ V3 has no additional RAM free for such features (only if you would get rid of useful features like Undo buffer and Mixer…)
But I could add a “cheap” version which disables all BLM buttons for a short moment (e.g. 20 mS). I guess that you wouldn’t really notice a difference, because it’s the same approach which MIOS uses to optionally debounce normal DINs, and nobody ever complained about this
Best Regards, Thorsten.
i suspected this was too expensive, sounds like the 20ms would be fine though.
when pressing several buttons at once, the lag would be <number of simultaneous buttons> * 20mS, right?
just to be clear why i asked this: i am planning to build an extension module and connect it to the main seq with say a db9 connector, carrying only the din/dout signals. sounds like if other folks follow this and want the track group buttons on the extension (i think only makes sense for existing v2 seq), they will need to add these…
It also makes sense for MB808, so would be nice if you could prepare it.
Btw.: I’m interested in the extension module as well!
when pressing several buttons at once, the lag would be <number of simultaneous buttons> * 20mS, right?
No, the lag is always 20 mS (or the configured debouncing time) - independent from the number of simultaneous pressed buttons.
And: a lag/delay will not happen, if the there wasn’t a button event for more than 20 mS
Please note, that I’m using duo-colour LEDs for group indicators as well, but only one LED colour is used by the MBSEQ firmware yet. The currently relevant DOUT pins are D7, D5, D3, D1 for group 1/2/3/4 (D6, D4, D2, D0 are connected to the second colour LED, and is reserved for future extensions)
Although LED assignments can be easily changed in the setup_*.asm file, it makes sense to consider such details
Although LED assignments can be easily changed in the setup_*.asm file, it makes sense to consider such details
…
agreed. the customizable nature of midibox is one of it’s best features. but i think in these cases it is better if the hardware is consistent, since it will be easier to troubleshoot, maintain, manage software upgrades, etc