Sequencer design for feedback

[stryd_one]

Hi all,

It's been suggested that I should post this to the forum, as some people have missed it hiding out in the Wiki, so you guys can check it out and give any feedback you might have:

The MIDIBox Sequencer vX is an x0x style sequencer with multiple syncronised clocks which trigger single-track patterns, of which the steps can run programmable functions which include internal control functions as well as more conventional functions such as sending MIDI notes.. It's something like a rack of analog sequencers which can re-patch itself and tweak it's own knobs, which is triggered by independent but syncable clocks.

vX

It's a big read, but hopefully not too boring ;)

Hope you all enjoy it... Please let me know any thoughts/suggestions/problems/wishlists/etc :) Even if you just want to say "You're crazy and that sucks" it would be nice to get some feedback ;) There are lots of clever people here, I wouldnt presume that I could think of enough the good ideas without your help!

stryd_one

[Twin-X]

Excellent documentation Stryd.

My compliments. Keep it up!

[drin]

Hey stryd! Great work, and I'm looking forward to working on this in whatever way I can!

-drin

[monokinetic]

ok I had read this briefly once but your forum message reminded me to double check......

WOW! That sounds rocking, exactly the kind of thing which will have me soldering again for many hours, wahooo :)

thanks for releasing such comprehensive documentation, I'm looking forward to this one!!

dave mK

[chriss]

hi stryd_one

that sounds awesome

i mean i don´t´understand alot but i am still impressed of your work

chriss

[stryd_one]

Let me know if there's anything I could explain better, I'm very happy to do so, it's good for the project!

[stryd_one]

Hi TK, I hope I can ask your advice, forgive me as I have asked this question before, but I came across something on the forum today:

SDCC produces very large code on array accesses, you can propably boost your DIN matrix handler by factor 10 and more, when you are implementing the handler in assembly language.

I was originally going to do the seq in ASM but you suggested C, but I was planning on using arrays fairly heavily (which I didn't mention at the time) so I'm now thinking that ASM might be better after all?

Danke :)

[TK.]

As mentioned somewhere else, it makes sense to start with C, and to optimize small routines in assembler later. If arrays are used heavily, it isn't said that this will slow down the overall performance significantly, because this depends on how often the appr. routines are called. You will be able to test this once the C routines are working, and a translation (of time criticial parts) to ASM will be easier afterwards, because you  should already have a working algorithm at this point.

So: don't use the time to search in the forum for statements which are not 100% matching with your project, but just start programming and make your own experiences! ;-)

Best Regards, Thorsten.

[stryd_one]

Ahh Thanks TK, now I understand...

I know that the array functions will be called frequently, but even so, if I start with C code, I can make it work easily in C, and then port to ASM later, when I know that the algorithms work...

Thanks mate!

[moogah]

OOOH!  Good stuff there, I've been thinking about a sequencer like that for a few months now, but I think you've nailed it! 

    A few thoughts: 

-Along with step funcitons have "triggers" which are simply an IF statement, so that you can specify an event that triggers an event without having to place it on a timeline, or specify a condition like when pattern A1 is also playing reduce CC6 by 25. 

-Strange tap tempo functions, like ones that will slow down if you stop tapping

-Differentiate between patterns and tracks so that you can easily get "that bassline" or "those drums" from one pattern to another or create sequences live, which leads to:

-Creating a "palette" of patterns that can be played/muted using the 16 step pad

-The tried and true rest/slide/accent shouldn't be ignored, and I like editing pitched sequences using prev/next step buttons and a mini keyboard (x0xb0x style) I was thinking about a sequencer that had 2 edit "pads" one being the mini keyboard and the other a 16 step, each one can select any given pattern to edit.

-Map *everything* to midi notes  ;)

Obviously this is a whole hell of a lot to get into a PIC, but I'm willing to help out ;)

[stryd_one]

Thanks for the awesome feedback mate :)

Some great ideas! I'm updating the doco tonight to include all those things, I'll put it in here in a nutshell too.... Stay tuned.

Edit: Moogah, before I go ahead, would you mind explaining the third one for me (differentiating between patterns and tracks)? Just want to make sure I've understood you correctly, which I don't think I have :\ Thanks!

[moogah]

Sure, keeping in mind I don't have a working SEQ in front of me, so perhaps this will sound odd. 

Instead of storing an entire pattern with it's 4 parts as a single chunk of data like the SEQ, store the parts seperatly and create patterns which are simply a collection of parts that can be played together.  This way, when you start jamming you can simply import the drums from another pattern and get going right away.  This way you have a 'library' of parts and each pattern is just a group of parts, connected by your sequencer timing magic.  Your design accomodates this quite well I think since all you would need is the handle to a part stored in the pattern data to call a playPart() type function.  Now, so that a special "part edit" mode is not needed some logic would be neccessary, see if this makes sense:

Pattern 1 contains:

Part A

Part B

Pattern 2 contains:

Part B

Part C

If I begin to edit Pattern 1 and make changes to Part B the sequencer automatically copies that information into a new part and changes the handle in Pattern 1 from part B to Part D so that Pattern 2 is not effected.  If I am editing Pattern 2 and decide I want another part the sequencer simply creates a new part adds it to the list of parts included in Pattern 2.  You can kinda think of each Pattern like a 'window' looking into the big list of parts and allowing the user to select only those they are interested in for playback or editing.

Also, I should elaborate on the "triggers".  I had originally been thinking of this as a software sequencer, so perhaps it's really just too complicated to implement in hardware..  Consider being able to set a "Rule" for a pattern so that if part A starts playing, Part B gets muted or if Patten 1 gets cue'd then play a fill (think about that one!).  What would be needed is a way for the user to specify events and choose a function to call on the occurance of that event.  It is fairly simple to setup a trigger that will respond to the midinote #120 being played, but more complicated to specify that if one event is happening and another starts then do something.  It may also be too difficult to get a PIC to do all the checking neccessary to recognize certian events, I believe it would be neccessary for the uC to 'look ahead' for events only when there is a change of state in the sequencer like a part being unmuted, a new pattern getting cue'd or some incoming MIDI.  I've got some logic written out here, and I'm sure it can be done, it's a matter of what kind of interface would be needed to make it useable. 

I also think it's quite important to never have to stop the sequencer.  I don't recall exaclty how the SEQ works (I had to take mine apart for other prototypes) but the user should be able to switch from pattern play to pattern write with the press of a button.  Essentially pattern play mode is simply a lock on the edit buffers, which frees up the edit buttons for playback specific functions. 

Oh yea, reguardless of the EUSART getting working with the new PIC I'm giving a BIG thumbs up to the idea of incorporating midi synced LFO's and other such goodness.  The sequencing you describe BEGS to be connected to modular equipment through an AOUT

By chance your interested in splitting this project up?  I won't have alot of time to work on it until this summer, but I'm really interested in seeing a next gen sequencer become available!

[stryd_one]

Thanks moogah :)

Some thoughts:

Instead of storing an entire pattern with it's 4 parts as a single chunk of data like the SEQ, store the parts seperatly

This is already done, as the patterns are currently only a single track...

and create patterns which are simply a collection of parts that can be played together.

This is a really good idea. I'm not sure if it would work out quite like you've explained it, but something similar should be doable...

There is no edit mode in the vX because it is essentially always open for editing... Currently the design is such that each row of buttons on the UI can be set to display/edit the contents of a certain track, so you would get 8 patterns displayed at once. They could be patterns 1-8, or patterns 1,6,8,10,2 and 15 or whatever tracks suit your needs... But it should be possible to create a "UI Template" that will set the UI to expose the contents of a certain set of patterns together for viewing and editing. Does that sound OK?

If I begin to edit Pattern 1 and make changes to Part B the sequencer automatically copies that information into a new part and changes the handle in Pattern 1 from part B to Part D so that Pattern 2 is not effected. 

This one would be pretty easy, just need a "Copy & Edit" feature (Combined with UI Templates as above)... but it couldn't be automatic - because the sequencer is always in 'edit mode', how would the seq be able to tell which changes you make require copying to a new track and which do not? Anyway, because you don't have to change modes, there's still the same amount of button-presses to get the same functionality... Would this suit your needs?

The triggers part is real tricky... One of the scenarios you mentioned is already possible.

Consider being able to set a "Rule" for a pattern so that if part A starts playing, Part B gets muted

For this one, you would have a third part (Part C) which would be synced to the same clock as part A, and it's first step would run a function which mutes Part B

For the other one

if Patten 1 gets cue'd then play a fill

...that's tricky... I am not sure it's doable though, but I really like the idea... Here's a couple of thoughts, I hope you can find ways around these, I couldn't :(

Certainly, it would be impractical to scan the database for changes, firstly, how often would you scan it? It would be far too large to scan every tick, and you'd need to do it that often in order to be effective, and also without knowing which function was calling the data, it would just be a change of a value, and for example it would be impossible to tell if a note number had been changed or a CC number, as the functions that send that data both use parameter 1.. Likewise, if a step had a value change for parameter 3, then you wouldn't be able to tell if it were a note length, an NRPN byte, or a divider for a clock to be setup... The use of the value would vary depending on what function was set for the step... I won't go on, obviously it would only work if it also scanned for other data, meaning it would take too long.

This means that the sequencer would have to check for the changes as they were written to the DB, not later. If a set of parameters were defined in a table as conditions, and a matching set of parameters and a function number to pass them to, then the table could be scanned before values were written to object parameters in the DB, and if it matches, then run a function. You could easily set several conditions to match up like this too...  but there is a problem with this - again, table lookups aren't quick, and this could severely effect the realtime functionality of the sequencer.

These issues could be avoided by reading ahead of time, but this won't work either, as if you read ahead and then a value is changed, then the conditions would no longer be met, but the function would still be run as it was set to do so ahead of time. Likewise, it could read ahead, find none of the conditions met, and then not run the function, when a parameter could be changed to meet the conditions....

I also think it's quite important to never have to stop the sequencer.  I don't recall exaclty how the SEQ works (I had to take mine apart for other prototypes) but the user should be able to switch from pattern play to pattern write with the press of a button.  Essentially pattern play mode is simply a lock on the edit buffers, which frees up the edit buttons for playback specific functions. 

As for not stopping the sequencer, thats already in there :) Definitely a must-have for me, as the vX is designed for live improv, and having to stop would make it far less useful.. The way the seq works, is that as long as the master clock is running, it's always reading from the database and performing functions according to what it reads. If it reads that a pattern is playing, then it will check it's parameters for it's assigned clock, play the next step if it has ticked etc. If the track is set to record, then when the step is triggered, it will set it's parameters according to received MIDI notes or CC's. If you want to manually enter the notes then you can use the UI, by assigning a row of buttons to a pattern and selecting the step using one of the buttons and editing the step, or by expanding the track out so that each of the 12 rows of buttons is a pitch and each of the columns represents one step... it's like a piano roll. All of these modes operate simultaneously, only recording from MIDI input can be turned on and off.

I do like the idea of allowing the step buttons to have another function, but I can't think of what kind of things would be playback specific IE not writing to the DB?

Oh yea, reguardless of the EUSART getting working with the new PIC I'm giving a BIG thumbs up to the idea of incorporating midi synced LFO's and other such goodness.  The sequencing you describe BEGS to be connected to modular equipment through an AOUT

The EUSART bug no longer concerns me so much. MIOS 1.9 has made this matter more straightforward :) It will also mean that the vX will support multiple outputs for sequencing more than 16 channels of MIDI. The trick with the LFO's and envelopes and FX and such is that it could end up being rather CPU intensive (vector math...), so it would interfere with the operation of the sequencer... Don't give up on the concept though, because as you might have noticed, NorthernLightX and I have been brainstorming on concepts for MBFX, and I want to make them MIDI Clock syncable and remote controllable, so you could use the vX (or any other MIDI sequencer or controller) to program the LFO's and envelopes via MIDI or CV input, sync them to MIDI Clock or Sync24 and send their output either to the AOUT, the Digipots, or MIDI CC's.

I suspect I will include something similar in the vX, but not as advanced... You will of course still be able to use the patterns to send CC's etc, but the patterns are only 16 steps long... Fine for rough control, but not for smooth filtersweeps. I had hoped to include the ability to do interpolated values between steps, so that the seq would automatically smooth out the curves, but that's where the vector math comes in, too many divide operations :( An option I have considered is, the Envelope tracks and LFO tracks would have an extended number of steps... If the LFO pattern has a fixed MIDI output port, channel, and CC# with each step containing a value to be sent, then there are at least three unused parameters for each step which could be used inbetween steps. The problem with this, is that the LFO has to be triggered four times as often, meaning it would need a clock setup especially, and that you would have to draw the LFOs and envelopes in manually which means special UI handlers.

Regarding splitting up the project, definitely :) I must admit that I have a pretty solid idea of how this should be put together, and I do want to follow a certain method of construction, which will not only maintain the modular nature of the code, but build it from the ground up, adding one feature at a time, building up a set of frameworks for others to create sequencers according to their needs... I'm no dictator though, if we start work on this together and need to branch it in our separate ways then I don't see any harm in that :) I'm just stoked that you're interested, and thankful that you're interested in helping :D

Maybe with your help, we can find a way around the whole conditionally triggered functions thing... I don't know if it would be too complex, but it might take more resources (processing time) than a PIC has to offer :( Don't be discouraged though, see if you can find a way :)

[moogah]

Cool, your obviously knee-deep in this already, while I've just gotten my feet wet.  One more idea from my notebook:

"Booth" and "Program" patterns, rather like how a DJ has two different mix busses on his mixer so he can cue of the next track without the audience hearing it.  Now, obviously to make this really work the sequencer would need to be hooked up to a mixer so it's not a practical thing to do, but what sticks in my mind is the ability to begin editing a sequence before you start playing it back to the audience.  Good stuff for live improv!

As for what the edit buttons could be while in "playback" mode the first thing that comes to mind is part mutes.  This way you can spend time at a show layering parts into songs and easily switch into edit mode to make changes on a part that is playing (or about to play)

This one would be pretty easy, just need a "Copy & Edit" feature (Combined with UI Templates as above)... but it couldn't be automatic - because the sequencer is always in 'edit mode'

Hmm, good point.  I definiatly like sequencers that don't require a save button like this.  Copy&Edit really makes the most sense.

For this one, you would have a third part (Part C) which would be synced to the same clock as part A, and it's first step would run a function which mutes Part B

Could you also insert a "mute part b" event into the first step of part a?  In this case it would be an event that should happen before the first step of part a.  Triggering different sequences depending on the context of how they are being played brings up the idea of having sequence variations (a bit like the 808).

As for triggering a fill when a certian pattern gets cued, it's easy in a regular sequencer, all you need is globals for "prevPattern", "currentPattern" and "nextPattern" and have the sequencer check these values.  Good point about not being able to tell what a given argument is going to be.. that is going to take some pondering.

I'm down with sticking to a framework and keeping up the tradition of extendability that TK started.

[stryd_one]

Cool, your obviously knee-deep in this already, while I've just gotten my feet wet.

Only a year or two planning this thing ;) I can clearly tell that you've been thinking about something very similar though! :)

  One more idea from my notebook:

I love it :) Keep em coming man :D

"Booth" and "Program" patterns, rather like how a DJ has two different mix busses on his mixer so he can cue of the next track without the audience hearing it.  Now, obviously to make this really work the sequencer would need to be hooked up to a mixer so it's not a practical thing to do, but what sticks in my mind is the ability to begin editing a sequence before you start playing it back to the audience.  Good stuff for live improv!

Absolutely :) I mulled this one over a LOT... Basically I see two ways of doing this... Sending the MIDI to a different device, or setting the channel on the mixer to only play through the headphone buss... The first was in my original design, but at the time, multiple MIDI outs on a MIDIBox were not really feasable... Now that they are, we can just switch the track from one MIDI port to another, or maybe just change MIDI channel, or send a command for some kind of automation...For eg, I use a Behringer DDX3216 mixer, I could send automation to that to swap the buss of the audio channel playing the track... But I must admit that it seems a bit of overkill when the mixer would most likely be sitting directly next to the seq...

As for what the edit buttons could be while in "playback" mode the first thing that comes to mind is part mutes.  This way you can spend time at a show layering parts into songs and easily switch into edit mode to make changes on a part that is playing (or about to play)

Yeh I think the mutes are so heavily used that they'd have dedicated buttons...

Could you also insert a "mute part b" event into the first step of part a?

  In this case it would be an event that should happen before the first step of part a.

Well yeh you could :) Of course the tracks are monophonic (Geez I'd like to change that...vX version 2 perhaps) so if Part A Step 1 had that function, it wouldn't be able to have a MIDI note ...

As for triggering a fill when a certian pattern gets cued, it's easy in a regular sequencer, all you need is globals for "prevPattern", "currentPattern" and "nextPattern" and have the sequencer check these values.  Good point about not being able to tell what a given argument is going to be.. that is going to take some pondering.

yeh that prev/current/nextpattern stuff doesnt really apply in the case of the vX, because you've got all patterns running concurrently and  independently, and 'cueing' a pattern just means that you've set a bit that tells it to play the next step when the assigned clock ticks, as opposed to not even checking whether the clock has ticked, and moving onto the next pattern...

I'm down with sticking to a framework and keeping up the tradition of extendability that TK started.

:) I think at this point that I'll probably start with the clockbox and build it up from there. I don't know if you are comfortable with C, but TK has advised me that C is preferable over ASM, and seeing as we have AudioCommander's badass C sim, I think that's definitely the way to go. Any thoughts?

[taf]

So, I think this is my first post to the list, although I've been around here for several months.

First at all congratulations for your idea and your effort stry_one. Kudos also to TK. Great place

As many of us, I've been also thinking about a live performance oriented sequencer.

Although I use a set with monomachine+machinedrum UW, which are

great for live performance I've have always missed the possibility of having

more tracks available for direct editing. I like also Ableton live, but I'm more hardware

oriented. You can get some idea from this

video: http://monome.org/media/monome40h.mov

I was trying also to reuse as much as possible from the MBSEQ box, but adapting its

user interface to my needs, but your project provides so many good ideas

that I will try to use it. Even provide some help in case you needed.

So here there are some ideas in case they are of some help. Mainly related to the UI.

I was thinking in the following arrangement:

|---LCD---|

K K K ... K    E B R

                                                      b b b b

A                                                    s s s s

T  X X X X  X X X X  X X X X  X X X X  S S S S  P M

T  X X X X  X X X X  X X X X  X X X X  S S S S  P M

T  X X X X  X X X X  X X X X  X X X X  S S S S  P M

T  X X X X  X X X X  X X X X  X X X X  S S S S  P M

...

T  X X X X  X X X X  X X X X  X X X X  S S S S  P M

T  X X X X  X X X X  X X X X  X X X X  S S S S  P M

T  X X X X  X X X X  X X X X  X X X X  S S S S  P M

T  X X X X  X X X X  X X X X  X X X X  S S S S  P M

Ki: Param Pi edit knobs. (e.g. One knob per layer in the MBSEQ)

Ti: Track select pushbutton with LED

Xi: Step ON/OFF pushbutton with LED

Si: Select slot pushbutton LED (at least four, but could be more)

Pi: Play mode select pushbutton

Mi: Mute ON/OFF pushbutton with LED

B: Begin of sequence pushbutton

E: End of sequence pushbutton

R: Random mode pushbutton

A: Select all pusbutton with LED

si: Select column of slots pushbutton with LED

bi: Bank select with LED

General principles:

All the steps in the sequence shall be available for direct editing.

Pushing any button at any row, implicitly selects the track involved

Any edit operation during live performance needs only a pushbutton operation.

A pushbutton operation can be simple (e.g. X on/off) or multiple (e.g <B> + <Xi> simultaneously).

Any pushbutton can have three behaviors.

- Short press and release. (e.g. on/off of a step or slot select)

- Press, and while pressed modify other UI element. (e.g. Press <Xi> and tweak param knobs for this step)

- Long press, performs predefined action. (e.g. Long press <Si> stores current pattern in slot Si)

Ideally pushbuttons with led will be tricolor, so different status can be displayed (e.g. step muted)

Additionally there will be buttons for common operations, like transport (play, stop,...), menu management, tempo, etc.

- Up to 16 tracks can be played simultaneously.

- The configuration of 16 tracks x n banks x m slots, is stored as a song. Total number of songs depends on memory and n, m.

In the example n and m are four, that seems adequate for live tweaking (16 tracks with 16 patterns each one).

- There is no save action, but I think it is useful that when you are tweaking a pattern and you find some variation that you like, it

can be saved to a slot for later recall. At the beginning all the slots are empty

Some examples:

<Mi>: Mute track

<Mi LONG PRESS>: Clears all the steps

<Mi> + <Xi>: Mute step Xi

<Ti LONG PRESS>: All the steps ON.

<T> + <R>: Initialize Ti pattern with a random steps configuration

<Ti> + <Ki>: Modifies param  i for all the steps in the track

<Xi>: On/off step Xi

<Xi> + <Ki>: Modifies param i for the step. LCD shows different param values for this step

<Xi> +...+ <Xj> + <Ki>: Modifies param i of steps i,...j(e.g. you can push several steps for editing. Alternate mode: When some

step is muted, only unmuted steps are affected when edited doing <Ti> + <Ki>.

<B> + <Xi>: Selects Xi as the first step of the track (Changing time signature for this track on the fly)

<E> + <Xi>: Selects Xi as the last step in the track (idem)

<Si>: Select slot Si. Track will start to play Si depending on track play modes (e.g. immediately, beginning of next cycle, ...). So for

          each track you have a set of variations (4 in the example).

<Si LONG PRESS>: stores current track in slot Si

<si>: Select column of slots for playing. So you can use each slot column as a song section, as in live

          left hand row (e.g. INTRO, CHORUS,....)

<P> + <K1>: Selects playing mode for track (forward, backward, ping-pong, random,...)

<bi>: Selects bank bi. (e.g if there are four slots for each track, and four banks, we have 16 slots per track)

I hope that you get the idea with the examples.

For the hardware I was thinking in doing something modular. Well this is true for all the MidiBoxes I'm playing to build.

The idea is to have a common module for basic functionality and a set of specific modules for additional functions.

In this case a set of four track rows that can be incrementally added.

So you start with direct editing of four tracks and you can go 8, 12 or 16 with time. So

it can be accommodated to any budget. I would like also to reuse this module for other Midiboxes

(e.g. Ableton live controller).

Well, I'm doing lot of designs and finishing 3D renderings, in case anyone is interesting in providing

some feedback. I hope to finish some for this week.

Something I'm also thinking from the point of view of UI and overall software to

develop is that at some moment you would need to chose between a

performance oriented sequencer and a programing oriented sequencer. I feel that

maybe too much of the two could make the system somehow confusing.

sorry for this unordered exposition of ideas. I didn't write nothing formal, just thinking about how I would like live hw sequencing.

[stryd_one]

Welcome to the list! :)

That's dead similar to mine! :D

Only reason I haven't published anything yet is that I didn't have a way to display it, I like that ASCII style annotation :)

I have lots of comments so I might sketch up something similar and post back tomorrow night, thanks for the input man!

[stryd_one]

Even provide some help in case you needed.

Thanks :)

So here there are some ideas in case they are of some help. Mainly related to the UI.

I was thinking in the following arrangement:

I'll just reel off thoughts as they come to me, sorry if this ends up being a bit erratic... I'm just sharing some ideas I've come up with, but there's no pressure to take my lead on any of this stuff :)

First thing, jumped out at me... I don't want to section things into lots of four. One of the aims of my project is to educate the world on the wonders of time sigs other than 4/4 :) Obviously, that's just a matter of drilling anyway :)

I wanted the LCD (4x40 for sure) on the bottom so it is more easily viewed, and centered or towards the right, so it is near the right hand (aka tweaking hand hehe)

16 columns of buttons is a lot, and would be awesome, but will probably necessitate a second core for the CS. I wanted at least 12 rows for an octave worth of buttons in grid edit mode and 8 columns of buttons per row, as the base unit (without additional modules) but more on that later.

I think bank/slot could be limiting (more on that later, but it's because of the pattern grouping problem) I was thinking of an encoder to select which pattern is assigned to the track. This brought me to another thought, of having a vertically mounted 2x40 LCD to display track info like assigned pattern, start step, end step, current playing step, play direction, loop mode, etc... Although bank/slot would be a nice intuitive way to arrange the track assignment templates that were mentioned earlier in the thread

Need buttons for the clocks

I don't know about the press+hold thing, that's a bit prone to error if you're too short or long in your press by accident, and slowing movement around the control surface ... I'd be inclined to put a Shift key on there. You can also use this for other things like fast encoder speeds

The vX would do well to have transport buttons for each track..

16 tracks fixed might not work out... There are two things that will control the number of simultaneous tracks - utilisation and memory. Assuming memory won't be an issue (4620 and SRAM should have that taken care of) then the limitation will be utilisation, and that will vary from song to song. Much more will be known when I get building.

Okay back to the bank/slot/pattern thingy, as I somehow spaced out and forgot to mention in my post to moogah, I'm yet to come up with a way to get the patterns into some kind of group... If you're still keen to help, see if you can think of a way to group the floating patterns. Welcome to my hell. Every time I think of a way to do it, I find a problem with it  :-\ Ultimately I want an "Alias Pattern" which would have a list of it's children, and would pass it's input onto each of them.

Regarding the modular hardware, definitely, I wanted extensible pattern modules so you could have strange numbers of steps happening, so that 7 step patterns will be physically aligned with 8 step ones when playing in sync

at some moment you would need to chose between a performance oriented sequencer and a programing oriented sequencer. I feel that maybe too much of the two could make the system somehow confusing.

Ahh now you're talking ;) This is part of the scheme with the vX that I haven't talked too much about yet. Obviously the more complex functions are the kind of thing that can be a hindrance during a performance... or at least leave you hunched over the console ignoring the crowd = bad. Although I plan on fully exposing the complete set of features to the UI, the more complex features of the seq, such as programming algorithmic sequences will be best editing using a PC. MIOS is totally bitchin, but for really complex user interfaces, a mouse, keyboard and a pair of 21" monitors is hard to beat  ;D Drag'n'dropping sequencer objects on screen into parameters for internal control functions, 'patching' clocks into patterns, etc etc. I'll cross that bridge some more in a year or so when it's reached that stage... But yeh, I agree.

Look, regarding all thoe other stuff, which I didn't respond to directly, just assume that my response is somewhere between "Hey you stole that idea from me!" and "That's a good idea, can I steal that?!"  ;)

Any thoughts on all this? I won't presume to do the ascii art UI diagram like yours until I hear your opinions.

As for your offers to help, I'd be especially appreciative of any suggestions of how to implement the grouping of the pattern modules.

They need to operate in a fashion that allows the track to continue to operate independently

They need , when the target of a function, to be able to act as a conduit for data through to the individual patterns, or act as an overlay which leaves the member pattern untouched and only modifies it's contents when it is played as a member of the grouping

They need to be able to be scanned for assigned clock ticks without interrupting the flow of pattern scans and interrupting realtime operations

At the moment I was thinking of making them appear almost like a normal pattern which acts as an alias in the above fashions, but I think it will require a kind of second sequencer engine, so the first engine scans patterns as per the current documentation, and the second scans the group patterns and plays them in a special manner. That's pretty drastic though, I'm hoping for an easier way...

:o Another Bloody Long Post from me

[taf]

These days things are a little busy around here.

I'm also reading the manual from the octopus. Once finished I hope to make

some kind of reference model in order to compare diferent systems.

This link is interesting http://www.sequencer.de/specials/sequencer.html.

Lot of sequencers than can provide good ideas.

Some time ago I studied also the manuals from the schrittmacher and the Sequentrix P3.

This new Octupus http://www.genoqs.net/ seems one of the most powerfull step sequencers I've ever seen.

The Story board is an interesting reading.

The more I know about these commercial products and how they work, the more I

think that TK has done a excellent work on the MBSeq. Would be interesting,

what are his ideas for v2. I hope he takes the same route as with the MBSID v2

(go with the more powerful PIC18F4620 and overcome its bug with the new I2C

MIDI module).

Give me a couple of days to comment on your questions.

[stryd_one]

Heh, I'd never heard of the octopus until I read that post, thanks for the heads up mate :) It sounds very much like the design for the vX was at that time :)

All that other reading, I did a few years ago when I started, and took away some ideas, but basically, because the vX handles things so differently, not many of the concepts applied. By all means have a look though :)

And take your time replying... But just a tip, the vX is supposed to be something -different- to the norm, so don't get too stuck in trying to replicate features from a device which is the norm ... Forget everything you know abut music, and start thinking about fractals and prime division :)

I'd very much like to hear TK's ideas for the SEQv2, but it might be early days for that right now...

[docbrown]

Stryd,

Vx sound very nice, it seems very flexible!! Keep up the good work. Good luck! :)

docbrown..