Strictly MIOS alternative sequencer thread

[DrBunsen]

Hi,

There have been a lot of suggestions for different ways of working with the SEQ, and it's not realistic to think that TK should try and incorporate them all into his design.  He has a particular workflow in mind, and that is getting more and more perfect over time.  And there's a limit to how much more can be crammed in.

But that's the beauty of the open platform, isn't it?

What I'm suggesting is that everyone who is interested in different sequencer paradigms, should gather together and work out some new firmwares amongst ourselves.  

To me, this is a great opportunity to learn some microcoding and system design.

This thread http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=concepts;action=display;num=1073852710;start= started promisingly, but the ideas within it have come up against the limitations of the PIC platform, and has moved into discussion of embedded Linux and other higher-order environments.  And I wish them all luck.

What I'm proposing here is that we stick within the capabilities of the PIC and MIOS, use as much existing code and hardware design as possible, but get creative about what we can do within that.   Starting with simple cases and building up.

I'm not suggesting that the other direction is a lost cause or anything - it is just not what I am personally interested.  Indeed I expect if this thread takes off, it could spawn more than one direction of development of its own.  And any new code or hardware we come up with will feed back into the MIOS community.

The first thing I will do is attempt to gather together and summarise all the ideas that have been put forward for alternative sequencers, and add a couple of my own.  Then we can work out which of those are realistic PIC-scale projects, and which are not.

Your thoughts welcome...

[arumblack]

I believe the current updates are very promising! i was interested too see how far the pic could be pushed, but quickly my desires exceeded it, hence the linux route(supported by mbhp controls). however, with smaller aspirations the code could be manipulated into other useful forms. A strictly X0X style drum sequencer would be totally badass, and i believe entirely within the pics performance range.Maybe even the triggers could be integrated?

[DrBunsen]

So there's a suggestion already!  And a nice simple one too by the sound of it.

:P No summary tonight, must ... sleep ... dream of hot ... solder and ... microcode ...

[DrBunsen]

Another simple starting point I thought of was a "tape style" 16 track sequencer.  ie simply records incoming note information from a keyboard.  With stop/start/rewind/ff, punch-in and punch-out (maybe as a footpedal), and track select buttons.

I'm sure we'll all end up with even more respect for TK's coding skillz before this is through :)

[DrBunsen]

Here's some helpful hints from TK:

There are a lot of enhanced methods to make such a sequencer more powerfull, you could either use external SRAM (e.g. 128k, battery buffered - I already wrote how to realize this), or you could implement a bidirectional interface between multiple cores ... And here is the problem --- the delay: I guess that a slave is always so busy, that a latency of less than 100 uS cannot be ensured --- so, forget the parallel core concept with bidirectional transfers, it doesn't really help.

If you are thinking on an alternative sequencer concept, then maybe a sequencer which doesn't work step-based? Ok, such a sequencer definitely desires more RAM -> think about an external RAM extension

Or you are thinking about a step sequencer which isn't so flexible like MBSEQ, but is optimized for dedicated jobs (e.g. a drum machine) -> don't use 3 layers, but think about another data format to save the step information. For example, you could run 32 tracks in parallel, every track assigned to a single note, velocity and gatelength. You only want to control the "mute status" and "accent". Result: instead of allocating 32 tracks * 3 layers * 16 steps = 1536 bytes for the layer information, you would only need 16 bit * 32 = 64 bytes for the accent flags plus 3 * 32 = 96 bytes for the note/velocity/gatelength which is used for the whole track (mute flags are already stored in the track record)

Ok, I think this is enough to give you some impressions about the art of system programming ;-)

Best Regards, Thorsten.

[DrBunsen]

Here's the summary I promised earlier.  Some of them are adaptions/additions to Thorsten's SEQ, some have already been at least partly implemented, and some would require completely new firmware.

/edit/ I hope modifying this entry doesn't bump the whole thread  :P

Alternative Sequencer Feature Ideas

Roland x0x style - many requests

stryd_one's vX or on the wiki

"Classical" style - cjlargear

an RM1X style of sequencer or a step sequencer with the capability to chain patterns in a song and to store them in a bankstick.

/edit/ the SEQ V2 has many if not all of these features

Sampler

Portable battery powered

SID+SEQ nb:

1: The MIDIbox SID firmware already comes with a 3 track 32 step sequencer with very powerfull functions (especially the combination between this sequencer and the arpeggiator makes a lot of fun). You have to modify the source code if you want to have another user interface like dedicated buttons for the sequencer, more LEDs or whatever

/edit/ TK is now working on a control surface extension.

presets to apply to the layers i.e. ascending, descending, alternating, random

Polyphonic SID /edit/ the SID is now poly

Pitch quantized to scale or chord

There's an interesting rant about the history of sequencers at this page http://www.sequencer.de/english/index.html.  Oder auf deutsch http://www.sequencer.de/index.html                         

[arumblack]

I would like to be able to do pattarns of more than 1 measure, preferably 8 or 16(at least).

[TK.]

In MBSEQ this has been realized by chaining the patterns. You can also set loop points, if you don't want to waste the pattern memory with equal patterns

Best Regards, Thorsten.