Midibox groove

[th0mas]

Disclaimer:  I _really_ try not to post anything, ever, until I've written the code for it.  In this case, I'm actually interested in what minimal feature set I should include in my design, so I might as well talk about it as I develop it.  I don't consider it vaporware since I need it completed for a show on may 12th in one form or another :).

Basically the application is a 4-bar looping sequencer.  Based on clockbox, it locks to an external midi clock (I don't really plan on adding support for an internal midi clock as it's going to be always slaved to my mpc), and listens for midi events on a single channel.  If it's in 'record' mode, it adds any received midi events to it's buffer and will repeat that note at that offset to the four-bar loop.

in other words: you play four bars of music, it loops it.

Some added features I'm planning on:

* 'ignore CC' - basically it will not bother to play any CC messages that are in the buffer, or alternately not record any CC messages it receives

*reverse

*invert CC

*if there were enough RAM, an A/B mode to have two sequences stored.  I don't think so.

*sync output for the 1 bit groovebox.

I think the target hardware will have two alternate setups: CORE with LCD and 1 DIN (ie, MBSID step A), and also just a CORE with some of the LCD pins stolen for I/O and the midi channels hardcoded (or configurable through some arcane LED representation).

[audiocommander]

hey, that sounds great :)

(I don't really plan on adding support for an internal midi clock as it's going to be always slaved to my mpc)

I am currently working on an alteration of mclock with a master/slave mode (that means, if a midi-clock signal is detected on the input, it syncs to the clock; if not (anymore) it falls back to master-mode). quite simple, but working good.

I also detected some minor problems in mclock that could lead to buffer overflows.

If you're interested I could PM you my current working version.

If I can assist or help with this project, or just share thoughts, I'd be happy :)

A simple 4 bar recording/looping/syncing tool sounds really great to me!!

Cheers,

Michael

[th0mas]

Hi Michael,

I remember reading you post something about that modification to mclock you made.  If you wanted to give it to me that'd be great!

Cheers,

Tom

[DrBunsen]

So it's a MIDI version of a looper pedal?

[th0mas]

Exactly, plus whatever quick features I could add by filtering the MIDI data.  I plan on having some sort of trigger out to sync it to other gear, like my 1-bit groovebox.  Getting it to sync with a looper pedal would be pretty hot.

I've had some ideas related to CC filtering (randomization, scaling, etc) but for now I'm just looking at a 4-bar looper that can sync to my mpc and ignore CC at request.

For a UI I'm thinking probably four to 6 pushbuttons, similiar number of LEDs.  Each pushbutton will toggle a feature, the LED associated will tell you if it's on/off.  Plus an LED tempo indicator, that's about it.  The version that has a master clock ability will need LCD and at least an encoder, but I'm not as interested in that right now.

[audiocommander]

Hi Tom,

the main credit goes to TK, of course, who provided us with such a nice template :)

IIRC I changed

unsigned char mclock_ctr_measures; // counts the measures (up to 65535)

to be an unsigned int

...and I think there were one or two other minor issues, but I can't remember what they were.

I attached a zip with the modified mclock files and hope they are of some use to you. The master/slave stuff doesn't really take away much space nor processing power (IMHO), but it's a nice feature, where at least something is coming out of the box, even if there's no midi-in attached...

cheers,

Michael

Edit:

Whoops, I deleted an important define (wanted to keep away the unnecessary work-in-progress-stuff)

in ACSyncronizer.h has to be added:

[tt]#define MASTER_IS_ALIVE_COUNTER 4095  // detect timeout at MIDI_CLOCK receive[/tt]

ACSyncronizer.zip

ACSyncronizer.zip

[stryd_one]

Wow how did I miss this thread? Forum must've gone weird...

Anyway this is a great idea thomas! Tell us more about it... does it store each 'take' separately so that you can add and remove recorded loops? Or does it merge or overwrite to a single loop? How many entries are allowed per loop? how accurate (what ppqn) are the note entries? does it quantise? Do I ask too many questions? hehehe

[th0mas]

Hey stryd :D, I figured you'd show up here.

Anyway this is a great idea thomas!

Thanks!  Personally this is all I want for a sequencer right now, to be able to sequence painlessly on the fly.  I play synth in a electro/rock band, and my MPC does all drums, so this will be easy to fit in and give me the ability to play at least an extra synth part :D.

does it store each 'take' separately so that you can add and remove recorded loops?

At first it's going to be a single track of MIDI data, thats it.  I have to figure out what exactly my PIC will allow, the biggest issue is naturally RAM.  For now I don't want to get bogged down in EEPROM or bankstick read/writes, so everything persists in the onboard RAM.

does it merge or overwrite to a single loop?

Initial settings will have an 'overdub' and a 'replace' mode.  It will be smart in relation to CC messages (if the step's buffer is full it won't erase a keypress/release to write a CC message).  As mentioned earlier there will also be a button to ignore CC messages from the recorded entry so you can just tweak the knobs.

How many entries are allowed per loop? how accurate (what ppqn) are the note entries? does it quantise?

I'm still trying to work out the details of how to buffer steps.  Originally I thought a linked list, but the overhead is not worth the adaptability.  Then I thought of a static array of the full 24ppqn x 16 notes, but forgot that you can have multiple midi messages per MIDI clock slice.  It's a balance between CPU overhead vs memory usage, like anything on the PIC, and I don't know what the balance is like until I have the hardware built and can do some onboard testing.

For the first version (I want to play live in a couple weeks) I might just make it monophonic (only save 1 event per timeslice) and use a static buffer.  I'm thinking about some sort of heap structure to use space as effectively as possible, but the problem is once you have to store your timing offset in RAM (instead of it being how you determine your offset into your event array) you waste a lot of space.

[stryd_one]

heheh yeh I am a sucka for a new kind of seq :)

Sounds cool man, keep it up.

[DrBunsen]

Hell yeah  ;D

I plan on having some sort of trigger out to sync it to other gear

  ... and CV?

[th0mas]

I've been real busy :( and am trying to do a proper job on the hardware for this device (unlike some of my previous cases).

The software will be quick once the hardware is finished, at least :).

As for CV, I'd need an analogue out wouldn't I?  Support for it could be added but I don't necessarily know what it'd be for - my idea for the gate out was actually more like "Sync out", that you could wire it up with a transistor to trigger an audio looping pedal or anything with a tap tempo (my alesis modfx units for example, have tap tempo but no midi) to keep the non-MIDI gear in synth with the MIDI signal.

[ultra]

hi

have there been any developments on this?  it sounds like a neat tool.  kinda what an mmt-8 could do (?) but quicker to use!

[th0mas]

hi

have there been any developments on this?  it sounds like a neat tool.  kinda what an mmt-8 could do (?) but quicker to use!

not enough :(.  I have a TODO that can waste more of my time to parse than I have to devote to my projects in the first place.

[stryd_one]

Stryd_one's Law: Sequencer projects will always require a time commitment which is an exponential function of the complexity of the design and the originally predicted timeframe.

Meaning: It's gonna take way longer than you think because it's not as straightforward as it seems ;)

[th0mas]

Stryd_one's Law: Sequencer projects will always require a time commitment which is an exponential function of the complexity of the design and the originally predicted timeframe.

Meaning: It's gonna take way longer than you think because it's not as straightforward as it seems ;)

time to fix this and write some code at work :D

[audiocommander]

I have a TODO that can waste more of my time to parse than I have to devote to my projects in the first place

lol ;D

apropos "time to fix this":

the mclock code has also been improved (as ACSyncronizer) in my latest ACSensorizer release (see wiki). Maybe this is of some use; It doesn't use any buffers though, just timing stuff, master/slave support & auto detection (that means it can also receice clock signals in contrast to the original mclock example), and I fixed some potential buffer overflows.

cheers,

Michael

[th0mas]

ooh!  nice AC, thanks a lot! I just got the dev environment set up on my work computer and was going to start from scratch again from clockbox 1, but if you have all the sync issues dealt with that's half the battle :D

[ultra]

awesome!

if you guys create this, i'll be one of the first to build it :)

this is a very worthy project and i hope it sees the light of day.  thanks guys.

[th0mas]

Thanks a lot AC, I'm now using the ACSync code extracted from the rest of the ACSensorizor stuff.  I also got ACSim working in linux (required minor changes).

Right now am I right that the wiki is the only place to get the ACSim code?  I'll do a diff between my version and the version that's on there before putting it online, although I guess at least the wiki software tracks changes..

[audiocommander]

Hi th0mas,

great to hear that :D

The ACSim-Files contained in the Sensorizer zip file are probably newer than those on the wiki; if you got too much to do, I'd also be happy if you send me your adapted files and I can merge them and update the wiki (though I won't be able to do this this week, 'cause my 2DO looks probably similar than yours ;D )

Cheers,

Michael

[th0mas]

Hi th0mas,

great to hear that :D

The ACSim-Files contained in the Sensorizer zip file are probably newer than those on the wiki; if you got too much to do, I'd also be happy if you send me your adapted files and I can merge them and update the wiki (though I won't be able to do this this week, 'cause my 2DO looks probably similar than yours ;D )

Cheers,

Michael

Hey Michael,

  I'll hold onto mine for a bit.. I'll probably add a bit more to the simulator as I'm using it.

Cheers,

Tom

[julienvoirin]

so what's up with this project ? i am also interested, and really really interested to know how you record midi. I would like to develop a midi recorder. i have already some idea of the algorithm based on clockbox if it can help a little.

[stryd_one]

Yeh, bump! I liked this idea, I hope it's still cruising along. No rush of course, I'm many things but not a hypocrite ;) If I can help please let me know.

julien: If you want to record the data you save it to memory as it is received. You use the clock to run a counter, which you can use to address the memory. There are lots of caveats, that's a very simplified description ;)

[julienvoirin]

Hi Stryd

yes that is the idea i had. i have the schematic of an algorithm, based on clockbox with an independant RTC (rec time counter) driven by the clockbox. the problem i had was the buffers (Rx >> bufferA>>bufferB>> bankstick) and the arrays used. i did it with a superchampion of programmation (i am pure newbee, but understand fast). let me know if interested

regards

[stryd_one]

Sounds interesting, and I don't think we're hijacking ;) So go on... what was the problem you had?