v3 questions

[intellijel]

Looks like great work is being done!

I have some questions about v3:

1. ETA? (when do you think this will be released?)

2. Is there a cumilative transpose function (like on the notron)?

3. Chord strumming option?

4. Cumilative pitchbend with transposition time set per step?

5. Will there be additional or different hardware (PCBs) used from the older version of SEQ? (other than the matrix led addon...time to shop at Sparkfun!)

6. How about a function to sustain or kill all notes on a channel?

7. Option to pause at a particular step for a set number of step lengths?

8. Individual shuffle settings per step?

9. Skip step function?  (combining step pause, shuffle and skip step helpds create awesome swing riffs)

10. Option to quantise individual chords to a scale or not?

thanks!

intellijel

(lookign forward to this! I have wanted a Notron for years and this may be even better once it is all working)

[TK.]

Hi Intellihel,

asking questions this way implicates, that you would "only buy the sequencer" if all these features are implemented. Please note that this a DIY design, features are implemented as I find them useful, and as I find the time (currently I don't have that much sparetime)

However, to answer your questions:

1. ETA? (when do you think this will be released?)

It's already distributed via email to people who have built a MBSEQ V2

2. Is there a cumilative transpose function (like on the notron)?

I don't know, what this exactly means, could you please elaborate this feature request in more detail? Maybe it's already implemented under another name?

3. Chord strumming option?

no

4. Cumilative pitchbend with transposition time set per step?

see answer to 2

5. Will there be additional or different hardware (PCBs) used from the older version of SEQ? (other than the matrix led addon...time to shop at Sparkfun!)

As described in the wishlist: no

6. How about a function to sustain or kill all notes on a channel?

Could you please describe a usage example in detail?

7. Option to pause at a particular step for a set number of step lengths?

How should this be used?

Maybe it's better when you first build the sequencer in order to get familar with the user interface, thereafter you can give more explicit hints. Sometimes the most difficult thing is not the coding, but to find a way how the user can activate functions without clicking through 100tes of menues...

8. Individual shuffle settings per step?

already possible - and not only shuffle, but whole grooves (delay/length/velocity mod) for 16 steps (32 steps: 2*16 steps duplicated)

9. Skip step function?  (combining step pause, shuffle and skip step helpds create awesome swing riffs)

already implemented

10. Option to quantise individual chords to a scale or not?

already implemented

(lookign forward to this! I have wanted a Notron for years and this may be even better once it is all working)

I don't like requests like "it must be working like this or that device" - it's working how I find it useful. Of course, inspirations are welcome, but the implemerntation of certain features are sometimes not possible since they conflict with other things (e.g. implementation of the sequencer core engine, or available buttons on the existing user interface).

Best Regards, Thorsten.

[intellijel]

Hey Thorsten,

I think you have taken my questions the wrong way! I am in no way demanding that these features be implemented. Nor was I trying to imply that I would only build this sequencer if these features existed.

I have been following ucapps for several years and have built a couple of midi controllers and a midi2cv so far. I am also a hardware design engineer and have been recently doing research into building a sequencer. From what I can see, many of the features I would like are already implemented in your designs (thanks to your hard work) so I am thinking it will be a better investment of my time to examine what you have created and look at ways to modify or adapt the design. I am just trying to clarify what features exist (or what they may be called) and indirectly offering some ideas that you may want to consider adding (to this version or future versions).

It's already distributed via email to people who have built a MBSEQ V2

I did not realise there was an exclusive list for Seq 2, I will try to sign up for that.

2. Is there a cumilative transpose function (like on the notron)?

I don't know, what this exactly means, could you please elaborate this feature request in more detail? Maybe it's already implemented under another name?

ok this is kind of cool:  Let's say I had a 16 step pattern that is looping. If I put a tranpose of +2 on step 1, then everytime the pattern repeats, all notes following the transpose message will be transposed +2. So after one pass everything is +2, after second pass everything is +4, after 3rd pass through it would be +6 etc. What the notron does is provide a low and high note transpose limit that cause the cumalitive tranpositions to "wrap" around once they have reached a certain octave (e.g. if it has reached it's high limit, it will shift all notes above the cutoff point to whatever the lower limit is and start rising again, in this way you get amazing moving patterns). The limits make sure the pattern does not keep transposing upwards or downwards to infitiniti. 

You can see an example of this in the no!tron (a reaktor ensemble)

4. Cumilative pitchbend with transposition time set per step?

This is again based on the concept that if you pitch something up or down, it stays at that new pitch unless you tell it to change. So if I had a pitch bend of -3 on a step of my pattern, everytime that step is reached, the whole pattern will be bent down an additional 3 semi tones.  -3 then -6 then -9

So if you set one step to be -3 and then another stpe to be +3 bend, the pattern will be tranposed down and then back up by pitch (the net pitch bend is zero at the end of the pattern). If these steps also set different transpoistion rates (slide times) then you will get cool organic slides in the sense that the pitch bends will be moving at different rates for different notes. If a step has a pitch bend event AND its gate length is long (and you are controlling a polyphonic synth patch) you should get long gliding notes overtop of your sequence.

6. How about a function to sustain or kill all notes on a channel?

Sustain: Each step holds its note on (until perhaps the step is retriggered, yo don't want midi overflow)

When combined with pitch bend events you will get liquid riffs.

Kill:  The same as suddenly cutting your midi cable in half, e.g.  note on messages to a synth will sudenly be stuck. This is a cool way to get a pattern to suddenly have a strange breakdown... the effect it causes is also dependent on your synth you are controlling. e.g a pattern will suddenly be paused holding whatever notes were on at the time

7. Option to pause at a particular step for a set number of step lengths?

How should this be used?

This would be nice to have. Most sequencers get notes to sustain longer than a step length by tying steps together. In the case where your seqencer has indivdual control over note length, combining a long note length event with a pause of a certain step amount will give cool sustained notes.

Eg. Step one of a 12 note pattern has a 4 step pause and it has a long note event. If you played the pattern, you would hear a sustained note for a 1/4 of a bar (4 steps of a 4/4 pattern), then it would play the remaining 12 notes  (a weird way to play a 16 step pattern using only 12 steps).

If you start to play around with timing options like this you can begin to generate some really interesting patterns.

Maybe it's better when you first build the sequencer in order to get familar with the user interface, thereafter you can give more explicit hints. Sometimes the most difficult thing is not the coding, but to find a way how the user can activate functions without clicking through 100tes of menues...

Yes I agree, I hate menus and would like all functions (whenever possible) to have dedicated controls. They way you have implemented things so far is great. Depending on what new events/options are available per step I would add some more dedicated buttons to access those options. This kind of thing may not be so hard for me to add on my own if it is not integrated into the core design.

8. Individual shuffle settings per step?

already possible - and not only shuffle, but whole grooves (delay/length/velocity mod) for 16 steps (32 steps: 2*16 steps duplicated)

great! so I could go to one step of the pattern and set it to be delayed by a certain negative or positive amount and then go to another step in the pattern and do a different +/- delay?

I don't like requests like "it must be working like this or that device" - it's working how I find it useful.

As aforementioned I am in no way making demands! just asking some questions :)

Of course, inspirations are welcome, but the implemerntation of certain features are sometimes not possible since they conflict with other things (e.g. implementation of the sequencer core engine, or available buttons on the existing user interface).

So this is a big part I guess since you want to remain compatible with the existing design. hoever, with the addition of the matrix led/button option there may also be the opportunity to add more dediocated controls for some of the new features.

[TK.]

I think you have taken my questions the wrong way! I am in no way demanding that these features be implemented. Nor was I trying to imply that I would only build this sequencer if these features existed.

In the last time it happens very often, that people ask questions like "does MIDIbox XX support feature A like my favourite device B". This is what I find a little bit frustrating, because it definitely sounds like a demand, and leads the dialogue into a wrong direction.

So, let's talk about these topics on a different basis. I especially find it very important, that you now have descibed your ideas in more detail, this makes it much easier for myself to think about an adequate solution, instead of forcing me to work out a concept which could match with your wishes.

I did not realise there was an exclusive list for Seq 2, I will try to sign up for that.

there is no special list, I just send the snapshots to people who asked me for beta testing.

ok this is kind of cool:  Let's say I had a 16 step pattern that is looping. If I put a tranpose of +2 on step 1, then everytime the pattern repeats, all notes following the transpose message will be transposed +2. So after one pass everything is +2, after second pass everything is +4, after 3rd pass through it would be +6 etc. What the notron does is provide a low and high note transpose limit that cause the cumalitive tranpositions to "wrap" around once they have reached a certain octave (e.g. if it has reached it's high limit, it will shift all notes above the cutoff point to whatever the lower limit is and start rising again, in this way you get amazing moving patterns). The limits make sure the pattern does not keep transposing upwards or downwards to infitiniti.

You can see an example of this in the no!tron (a reaktor ensemble)

It is not so easy to provide two additional parameters (min/max limit) for such a minor feature. The reason is the way how I've organized the memory. Currently each track allocates 32 bytes for parameters, in the meantime only one spare byte is available anymore, and this is reserved for really important things, which could be added in future.

I don't want to reserve a larger area for track configuration data, since this wouldn't allow me anymore to store 128 patterns in a 64k BankStick (as programmer you propably know, how important the 2^x values are)

However, your idea can be realized on a different, and in my eyes on a much more flexible way. There is a CC for semitones, and another CC for octave transpose. Thanks to the internal loopback port it's possible to play these CCs from one track, and to send them to another track.

This means in other words, you can control the octave or semitone transpose from a second track. By setting the clock divider of this track to a high value, it's possible to change the transpose value after each 16 steps of the "note track".

One track can send up to 3 CCs

In addition, there are things possible, about you've propably not thought about yet. :)

E.g., the control track can be forwarded with a special progression pattern (what you see in the last video), or randomly, or manually, or ...

This is again based on the concept that if you pitch something up or down, it stays at that new pitch unless you tell it to change. So if I had a pitch bend of -3 on a step of my pattern, everytime that step is reached, the whole pattern will be bent down an additional 3 semi tones.  -3 then -6 then -9

So if you set one step to be -3 and then another stpe to be +3 bend, the pattern will be tranposed down and then back up by pitch (the net pitch bend is zero at the end of the pattern). If these steps also set different transpoistion rates (slide times) then you will get cool organic slides in the sense that the pitch bends will be moving at different rates for different notes. If a step has a pitch bend event AND its gate length is long (and you are controlling a polyphonic synth patch) you should get long gliding notes overtop of your sequence.

In general I don't support pitch bend anymore, since the MBSEQ works internally with 7bit values, so using Pitch Bend results into the same like using a CC mapped to a detune (finetune) parameter of the synth. The concept is flexible enough, that I could add a new event mode which sends Pitch Bender events, but I don't see much use for it.

But this is only some background information, and not the answer to your question.

Do I see it right, that you mean a semitone transpose - than it would work in the same way like for 2) --- yes, it's possible to control a "CC length", which means: CC will be set to the step value for a given gate time, and thereafter set back to 0

Sustain: Each step holds its note on (until perhaps the step is retriggered, yo don't want midi overflow)

When combined with pitch bend events you will get liquid riffs.

Currently this has to be done by setting the gate length to maximum, so that the step will be tied with the next step. By doing so, a note can be held over the whole track length.

But it wouldn't be so difficult to add a "sustain flag" - I will do this

Kill:  The same as suddenly cutting your midi cable in half, e.g.  note on messages to a synth will sudenly be stuck. This is a cool way to get a pattern to suddenly have a strange breakdown... the effect it causes is also dependent on your synth you are controlling. e.g a pattern will suddenly be paused holding whatever notes were on at the time

problem here is, that the sequencer has to memorize the played notes if they should be killed on command. This consumes a lot of memory - since there are 5 MIDI Out ports, and 16 MIDI channels, 10240 notes = 1280 bytes would be required (so much RAM is not free anymore).

A "All Note Off" CC could do the same, but most of the synths I own don't support this...

Alternatively Note Off events could be sent over all channels and ports, but this consumes a lot of time (for 10240 notes: 10 seconds)

This would be nice to have. Most sequencers get notes to sustain longer than a step length by tying steps together.

(this is possible)

In the case where your seqencer has indivdual control over note length, combining a long note length event with a pause of a certain step amount will give cool sustained notes.

Eg. Step one of a 12 note pattern has a 4 step pause and it has a long note event. If you played the pattern, you would hear a sustained note for a 1/4 of a bar (4 steps of a 4/4 pattern), then it would play the remaining 12 notes  (a weird way to play a 16 step pattern using only 12 steps).

If you start to play around with timing options like this you can begin to generate some really interesting patterns.

unterstood. Problem here is, that I don't know, where to store the pause within the layers.

Only possible position would be the gate delay, but it's already 5 bit (due to the 96ppqn resolution), and the remaining 2 bit are used for the double/tribble/quadruble step triggering.

What I could do is to add a mode, which turns the double/tribble/quadruble step triggering into a 2x, 3x, 4x pause, but I don't know if this is really flexible enough. And it would mean that I have to do a lot of changes at different places within the firmware, since such a change hasn't been considered at the beginning.

great! so I could go to one step of the pattern and set it to be delayed by a certain negative or positive amount and then go to another step in the pattern and do a different +/- delay?

It depends, for delay you can only set static values or the "groove intensivity" parameter, which can be changed via CC (think about the loopback possibility). Negative delays are not possible.

For Velocity and Length you can set percentages (20%..160% in 10% steps) or the groove intesivity parameter (again)

Best Regards, Thorsten.

[cheater]

I think the chord wrap is a nice idea.

You could sequence a chord or a few and then manipulate top and bottom wrap live to have fun... Very interesting to me, I remember playing around with this kind of concept manually in the sequencer, it sounds great and - best of all - doesn't produce inharmonic sounds.

You could set up the chords and wraps so two notes end up being wrapped to the same note -> velocities add. Then "unfold" the wrap and they split into their proper places. Both notes create the same musical "power" and are at the same notes (e.g. C) but transposed (for example you start out with C3 and this splits to C2 and C4 - the sequence goes from punchy to rich). I think those settings could be used for manipulating how "rich" a sequnce is, and also for so to say "pitch shifting" the sequence, while in fact you don't pitch shift: play the same notes, just transposed. This could morph a lead to a bassline and vice versa.

I think it would be interesting in the sequencer but I also think this could be realized in a separate MB! :) Perhaps a beginner project for me, we'll see :)

[intellijel]

This means in other words, you can control the octave or semitone transpose from a second track. By setting the clock divider of this track to a high value, it's possible to change the transpose value after each 16 steps of the "note track".

One track can send up to 3 CCs

I think this will only accomplish one half of what I was hoping for. This gives a way to send pitch/transpose messages at whatever rate I would like (using the seperate CC track) but there is no way to have the pitched notes wrap around the lowest or highest value not limit (another way to describe that is as "octave quantising").

In addition, there are things possible, about you've propably not thought about yet. :)

E.g., the control track can be forwarded with a special progression pattern (what you see in the last video), or randomly, or manually, or ...

yes that's another way to look at it, just look for creative solutions using CC coupled with MAX/MSP patches.

In general I don't support pitch bend anymore, since the MBSEQ works internally with 7bit values, so using Pitch Bend results into the same like using a CC mapped to a detune (finetune) parameter of the synth. The concept is flexible enough, that I could add a new event mode which sends Pitch Bender events, but I don't see much use for it.

I see... having only 7 bit values will definitely limit the PB. It may be cool in a future version to have high resolution pitch bends/CC and then have the ability to reduce the bit values (cool effect if one can set the bit depth, it would provide a way to emulate sample and hold)

problem here is, that the sequencer has to memorize the played notes if they should be killed on command. This consumes a lot of memory - since there are 5 MIDI Out ports, and 16 MIDI channels, 10240 notes = 1280 bytes would be required (so much RAM is not free anymore).

A "All Note Off" CC could do the same, but most of the synths I own don't support this...

Alternatively Note Off events could be sent over all channels and ports, but this consumes a lot of time (for 10240 notes: 10 seconds)

hmmmm seems like a lot of problems come back to memory limitations of the pic. Myself and soem firmware programmers I know were already impressed that you managed to fit a whole sequencer in there. What about making the option for a second core module to be used? Create a set of extended features that can be realised with the extra processor+memory? Or are there plans to use a different micro proc. in the future?

(this is possible)

does this mean that it is not possible for one note to be sustained overtop of another step?

e.g. If step 1 has a long sustained note (longer than a step lenght) and step 2 has a short note,  would step one sustain and then step 2 would play overtop of it while it is still sustaining?

It depends, for delay you can only set static values or the "groove intensivity" parameter, which can be changed via CC (think about the loopback possibility). Negative delays are not possible.

For Velocity and Length you can set percentages (20%..160% in 10% steps) or the groove intesivity parameter (again)

ok that sounds cool. I still have personally found negative/positive delay to be realy useful.

anyways, sounds like you have done the best you can. Still has awesome features and will be a tiny fraction of the price in comparison to a Notron, P3 or Octopus.  The illuminated step pushbutton extension will definitely increase it's allure (I just hope SparkFun get their act together and produce some more PCBs...they are losing money!)

cheers,

    intellijel

[TK.]

I think this will only accomplish one half of what I was hoping for. This gives a way to send pitch/transpose messages at whatever rate I would like (using the seperate CC track) but there is no way to have the pitched notes wrap around the lowest or highest value not limit (another way to describe that is as "octave quantising").

A primitive octave quantisation is possible by forwarding the note or a whole chord (up to 4 keys or auto-chord - 16 predefined key combinations) to a track in arpeggiator mode, because the arpeggiator allows you to select the key number and the octave seperately.

And since it is possible to split the transpose function from the arpeggiator function (transpose: left keyboard half or one "loopback" track, arpeggiator chord: right keyboard half or another "loopback" track), there are also some complex stuff possible here :)

But I know, this again is not exactly for what you are searching for. I would say: I will try to combine one or two parameters in single bytes to free some space within the track memory, and after the first or second release of MBSEQ V3, I can decide for which purpose these reserved bytes are finally used. If there is no better idea, a max and min limit with wrapping function will be included (for myself it's a minor feature)

I see... having only 7 bit values will definitely limit the PB. It may be cool in a future version to have high resolution pitch bends/CC and then have the ability to reduce the bit values (cool effect if one can set the bit depth, it would provide a way to emulate sample and hold)

For efficient handling a 16bit or 32bit controller would be required, so it can really only be considered in a future version (MBSEQ V4?).

I don't want to say, that the PIC is not able to handle 14bit MIDI values, I only want to point out, that in the MBSEQ V3 application the data and task handling is already so complex, that such features will only reduce the overall performance, and this is what I definitely want to prevent.

hmmmm seems like a lot of problems come back to memory limitations of the pic. Myself and soem firmware programmers I know were already impressed that you managed to fit a whole sequencer in there. What about making the option for a second core module to be used? Create a set of extended features that can be realised with the extra processor+memory?

The communication between two cores will cost more performance than handling everything in a single core.

One of my secret options, about which I already thought about, but for which I propably won't find the time (considered that I will start with MBSID V2 sooner or later) is the re-implementation of the sequencer engine in VHDL, so that it can run on a FPGA. This would result into the first true-zero-latency sequencer of the world ;-)

It could still use the MBSEQ V3 control surface, but only as a "entry terminal" to the engine, coupled via a fast interface.

But such a project would also increase the skill barrier for electronic newbies

Or are there plans to use a different micro proc. in the future?

My experiences with the new PIC18Fxxxx derivatives are so bad, that the next platform won't be based on Microchip products anymore. Maybe in 2008 I will look for an alternative 16- or 32 bit controller which fits the needs for a DIY project (which especially means: low-cost toolchain, high reliability, good worldwide availability, low support effort from my side)

It should be a microcontroller family for the next 10 years...

does this mean that it is not possible for one note to be sustained overtop of another step?

e.g. If step 1 has a long sustained note (longer than a step lenght) and step 2 has a short note,  would step one sustain and then step 2 would play overtop of it while it is still sustaining?

No, the first note would be stopped immediately before (no glide) or after (glide flag set) the second note. This is required to fasten the note array handling. Since 16 tracks can play up to 4 notes, the note array has 64 entries. On each 96ppqn clock, the sequencer has to process all entries - it has to decrease the delay counter and it has to send a Note Off event once the counter reached zero.

This simple handling speeds up the code at many places (e.g. it makes it easy to switch from one to another pattern without searching for "open notes" which relate to the old pattern), that I want to stick on this solution.

ok that sounds cool. I still have personally found negative/positive delay to be realy useful.

I believe this, but negative delays are not so easy to handle by the engine. E.g., I don't know how to ensure that the track is still on-sync when you are quickly switching between different patterns with different groove settings without waiting until the track has reached the end.

After I saw this desaster, by decition was: before spending some weekends in implementing and debugging new compensation and synchronisation routines, it's better to keep it simple at this place and to focus other features.

Best Regards, Thorsten.

[cheater]

One of my secret options, about which I already thought about, but for which I propably won't find the time (considered that I will start with MBSID V2 sooner or later) is the re-implementation of the sequencer engine in VHDL, so that it can run on a FPGA. This would result into the first true-zero-latency sequencer of the world ;-)

It could still use the MBSEQ V3 control surface, but only as a "entry terminal" to the engine, coupled via a fast interface.

But such a project would also increase the skill barrier for electronic newbies

I think the biggest success of the Midibox is that it can be assembled by newbies!

My experiences with the new PIC18Fxxxx derivatives are so bad, that the next platform won't be based on Microchip products anymore. Maybe in 2008 I will look for an alternative 16- or 32 bit controller which fits the needs for a DIY project (which especially means: low-cost toolchain, high reliability, good worldwide availability, low support effort from my side)

It should be a microcontroller family for the next 10 years...

Who ate 2007? ;)

[Mr modnaR]

TK (or anyone) how is it possible for an FPGA to provide zero latency?

cheers.

[TK.]

Who ate 2007?

2007 is the year of MBSID V2...

TK (or anyone) how is it possible for an FPGA to provide zero latency?

"zero-latency" can never be achieved, I took this term just to highlight, that a sequencer can be easily created on a FPGA with a response time of a small number of clock cycles instead of tenthousands... it depends on the complexity of the logic, and the pipeline stages. Assumed that the FPGA is clocked at maybe 20 MHz (to reduce the number of required pipeline stages), the whole update of 16 tracks would maybe take 50..100 cycles, with the result that all new MIDI events are ready to output just after 1 or 2 uS after the clock has been received.

This would be 1000 times faster than the PIC implementation, and latency could be reduced even more by spending more by splitting the engine into 16 units and processing the sequences in parallel (however, this would cause new problems, e.g. arbitration and loopbacks...)

Hope that you now don't think that a PIC would be too slow.

For comparison:

  - the latency of a common USB MIDI interface is 4..10 mS

    you are using such MIDI interfaces when controlling synths e.g. from Cubase, Logic, Live or whatever

  - the latency of MBSEQ V3 (and V2) on a received MIDI clock event is ca. 200 uS..3 mS

  - the latency of a FPGA based solution would be constantly the required update time, so let's say: 1 uS

Maybe it's better to call it "least-latency, zero-jitter" instead of "zero-latency"

Best Regards, Thorsten.

[Mr modnaR]

thank you for explaining that for me! am i correct in thinking that these FPGA chips are sort of 'hard' wired once you program them? or have i misunderstood?

cheers.