when will come the TR seq?

[stryd_one]

Hi Modularkomplex.

This thread is dedicated to emulating, and perhaps slightly improving upon, the TR style sequencers... What you're asking for is a different kind of concept to that, but if you'd like to help me with the vX, which is more like what you are asking for, just let me know :)

[modularkomplex]

Hi stryd_one,

I thought my suggestion is a slight improvement of the TR-Concept. It's the same way it works, just a bunch of additional track-rows. If there is a general dislike of implementing this as an option, ok.

I will have a look at the vX. (Must say I dont like the name, vx is a name for a chemical warfare Agent, too)

[modularkomplex]

Although: Would make much less sense than a selection

with the buttons of the row because an encoder doesn't show

the actual value. :P

So we should introduce enoders with a 16 LED ring around them. ;D

Hi sonicwarrior,

sorry, seen your answer late. Indeed, thats a problem with no actual value shown. I would suggest a 7-segment display per row but dont know the difficulties of implementation. OK, no enc, your track-selecetion method will do it.

[stryd_one]

I thought my suggestion is a slight improvement of the TR-Concept. It's the same way it works, just a bunch of additional track-rows. If there is a general dislike of implementing this as an option, ok.

I know what you mean, I thought the same... It seems that this thread/project is more about cloning the specific device, than creating a new but similar device. Some modifications to the traditional TR have been suggested, but larger scale changes such as those you and I are suggesting, appear not to be the intention of this project. Another thing which hasn't been mentioned as yet, is the requirement for CPU power. If the seq is busy scanning all those buttons, it might not have time for more important things like sending MIDI. This is a good demonstration why even if you were willing to write the code for the UI, it's capability and impact would need to be factored into the seq design from stage 1, and it's too late for that now.

I will have a look at the vX. (Must say I dont like the name, vx is a name for a chemical warfare Agent, too)

Well it originally stood for 'Version X' while I was toying with the concept, but that was shortened to vX because I'm bone lazy ;)

I'm aware of the nerve agent VX and actually thought that the name was well suited to the intention of the device - it's especially geared toward altering and mutating and growing songs - very viral in nature... and it's also designed to systematically destroy the existing, extremely Westernised concept of rhythm - it's a weapon against a few things I dislike about music in general. Not to mention that MSWord kept attempting to correct my spelling to "Vex", which reflects the way I feel about the 4/4 time signature fascination/addiction/obsession that people have developed/never thought to question ;) Other animals don't restrict themselves to 4/4, why do we? 'Cause people are stupid, that's why! ::)

Anyway I'm going further and further off topic every second I type. :-X back to the TR UI :D

[modularkomplex]

Hi,

yes, I didn't take the required CPU-Power into account. Did not thought this would be such a big problem.

I've read the vX-Wikipage and have to say that it is a really nice concept. But it seems it is a bit oversized for my actual needs. Since I'm a nerd, I would'nt deny to build such thing in the future. But for now I just searching a "simple to edit" drum-seq.

btw: nice explanation of the naming.

OK, because the lack of CPU-Power I'll have to rethink my favoured multirow-approach. Perhaps just combining 4 independent TR-Seqs in one Case.  ;D No, not really since copying, chaining... would be a hell.

[TK.]

Two comments from the programmers point of view: I think that the timings will be very relaxed, even with a large button/LED matrix, because it doesn't consume more CPU power, it only decreases the scan rate (e.g. on a 16x8 matrix, buttons will be scanned each 8 mS instead of each mS) - this is acceptable for such a device.

Another point: I think that you can increase the number of steps very easily to 64.

Here a calculation example: the gate of 8 steps can be combined in a single byte. This means, that 16 steps require 2 bytes, 32 steps 4 bytes, 64 steps 8 bytes

So, 64 * 16 steps are 128 bytes, and this range can be easily accessed.

Additional 64*16 bytes are required for the accent.

Accordingly, a patch allocates 256 bytes, and this means, that 128 patches could be stored in each 32k BankStick

What I'm missing a little is a "roll"/"flam" feature, it can be easily realised by sending 2 notes per step if the function is selected (like accent). However, this would also change the calculation for the patch size

Best Regards, Thorsten.

[stryd_one]

Ahh thanks for that advice TK. I mentioned the CPU because of your comments about the MBSEQ in another thread, but obviously these are different devices :)

[sonicwarrior]

I thought that list was meant to be a definition of existing "TR like" sequencers.

Ok, this is were we need a project leader who decides where to go. :)

So I'm not allowed to edit the wiki page? :-X

Also the phrase " At least 32 steps per bar as maximum" makes no sense.  "At least... as maximum"?

It makes sense:

You can e.g. set the maximum steps to 15, 31 and as the greatest (at least) value: 32.

Now clear? ;D

What I'm missing a little is a "roll"/"flam" feature, it can be easily realised by sending 2 notes per step if the function is selected (like accent). However, this would also change the calculation for the patch size

Well the problem I see here:

Would this work with analog trigger outputs?

With roll yes, but flam works with velocity, doesn't it? ???

[TK.]

Yes, you are right. Only roll would work with triggers, but if you add a MIDI function (which is very easy), you could support velocity in this way: default 100, accent 127, flam: 64..127

Best Regards, Thorsten.

[modularkomplex]

Hi,

since TK stated there will no problem with CPU-Power for the expanded Version with additional rows of Buttons/Leds I would like to hear the other contributors to this thread. What do you think about the suggestion?

[DrBunsen]

It seems that this thread/project is more about cloning the specific device, than creating a new but similar device.

No, I'm pretty sure everyone here has some improvements in mind over the original, just using the original TRs as a starting point for their familiar and user friendly UI.  Hence my suggestions about how to lay out the page - first define "TR-like", then list our suggestions for improvements.

Some modifications to the traditional TR have been suggested, but larger scale changes such as those you and I are suggesting, appear not to be the intention of this project.

Yes, that's my impression of this particular thread.  There are other threads with widely varying UI suggestions, which you can find links to under User Projects->Alternative Sequencers in the wiki.

But I don't think your design is a huge departure, sonicwarrior.  It's definitely TR-like and on-topic for this thread.

Ok, this is were we need a project leader who decides where to go. :)

So I'm not allowed to edit the wiki page? :-X

Leader?  We don' need no steenking leader!

Anyone's allowed to edit a wiki page.  I just suggested some improvements to make clear the difference between documenting the existing TRs and our improvements.

And I don't see this as one project either, with a proscriptive approach to what is and isn't right.  It's more like a starting point where people can build what suits them.  If someone comes up with a firmware and UI that everyone else likes, then cool, but I don't think we're all about The One True Sequencer here.  Hence no project leaders.

All just my own opinion and impressions.

It makes sense:

You can e.g. set the maximum steps to 15, 31 and as the greatest (at least) value: 32.

Now clear? ;D

Ah, ok I get you now.

Well the problem I see here:

Would this work with analog trigger outputs?

With roll yes, but flam works with velocity, doesn't it? ???

Perfect example.  I want velocity on my AOUTs, so I'm going to have to work that out for myself, with anyone else who wants to help.

I think I will go ahead and make the wiki changes I suggested.  Don't worry sonicdude, I'll preserve what you've added.

[sonicwarrior]

But I don't think your design is a huge departure, sonicwarrior.  It's definitely TR-like and on-topic for this thread.

Ok, now I'm relieved.  ;)

And I don't see this as one project either, with a proscriptive approach to what is and isn't right.  It's more like a starting point where people can build what suits them.

Ok, now I think I got it.

But in my eyes it's a bit confusing and will definitely delay usable results.

Perfect example.  I want velocity on my AOUTs, so I'm going to have to work that out for myself, with anyone else who wants to help.

Well, I don't have the skill to program the code nor do I have the time to learn it. :-[

So I'm dependent on what other people will program.

I can only help out by suggesting UIs and later by writing a user manual or WIKI entry or so.

Do you mean additional AOUTs for each DOUT (= trigger out) or

AOUTs instead of DOUTs?

The basis TR-like sequencer would have 1 row with 16 steps I think.

But nobody really said my design is shit. I don't think that I've found

a more complicated basis so easily. ???

Don't worry sonicdude, I'll preserve what you've added.

Ok, DrDude. :P

[DrBunsen]

OK, I've made my edits, comments and add-ons, alterations welcome.  I've defined the following sub-headings to make things clearer.

# Preamble:

# Defining/minimum Features:

# Extended Features:

# Desired Features for MIDIbox implementation:

# Extended Optional Features for MIDIbox implementation:

Do you mean additional AOUTs for each DOUT (= trigger out) or

AOUTs instead of DOUTs?

I mean optional AOUTs, one per instrument/track, replacing a DOUT, and up to the user how many they want to add. 

I have an idea for a low-low-cost AOUT:  a two bit (four values inc max and zero) AOUT could be built based on the AOUT_LC but using only two resistors in the ladder, and a minimum of code space.  That would give enough velocity variation for me.  Others might want to build a four-bit (16 step) AOUT or the full AOUT_LC.

Or I might use some cheap 8 bit DAC ICs I picked up recently:

the resistor ladder could be replaced by a DAC with parallel interface (see Karl's schematics), this would still have the advantage, that the DACs are accessible via a serial chain (-> low number of uC pins are allocated), and that the software driver doesn't need to be adapted for a proprietary interface.

But nobody really said my design is shit.

I don't think it's shit.  You should feel free to design what you want, that's what MB is all about.  Dream it, build it code it, share it, steal it, modify it :)

[modularkomplex]

Hi,

Ok, now I think I got it.

But in my eyes it's a bit confusing and will definitely delay usable results.

I think that, too. We should plan a base-version with not much more than the original TR-Features. Also, it should be simple expandable so everyone can build his own dreammachine.

We surely need a early feature-freeze. A Leader? I dont really see there has to be one.

[stryd_one]

I think that, too. We should plan a base-version with not much more than the original TR-Features. Also, it should be simple expandable so everyone can build his own dreammachine.

Bingo.

[cheater]

Hey guys!

I read the latest messages/posts on this topic. Very interesting stuff, we're finally floating away into the abstract ;)

What my dream MB TR SEQ would be:

16x16 LED buttons (although i'm definitely for adjustable rows with min=1 and max=+oo ;D )

Each row either has its own pattern of up to 16 steps, or continues the pattern from the row above it if the row above it has a pattern exceeding that row.

Each row has a small 8x1 LCD next to it. The LCD shows what the track's controlling (e.g. Snare or HiHat or BassDrum....). If the row isn't the first row for a pattern, the LCD is turned off (backlight off) - would be a great visual cue to see where patterns are placed on the controller, especially in unlit dance clubs.

An endless encoder for "scrolling" rows. E.G. you could have 128 or what ever rows and scroll around them. This would be most useful for people who have only 1, 2, 4 rows and want more control. Scroll up = top row goes to 2nd row, 2nd row goes to 3rd, ... nth falls off the surface ;) Analogously scroll down would do the opposite.

A knob for accent amount for each track wouldn't be needed - IMO the accent should always be sending the same thing, and you should set up how your synth/drum machine/etc reacts! Not the pattern. This enables you to have separate accent control per each device. However a global accent amount knob would be nice.

A knob for flam amount/mode/pattern (you could have different patterns/modes/flam amounts) and one for shuffle amount.

A switch for changing whether the surface is showing steps, flam, or accent, or a special "trigger mode" which works like NI Battery's GUI: each button = 1 track. LEDs light up accordingly when the track has a hit/flam/accent. Would be a great alternative step-wise pattern entry mode (not for live performance purposes, but definitely a nice tool to see your patterns in a different way!)

Two tempo buttons (+-1 BPM) and one endless encoder for changing the pitch +-0.05 BPM (for sync to DJ stuff).

Easy and fast change between patterns (very important! part of the performance abilities of TR sequencers): perhaps a separate keyboard or something.

MIDI out (no AOUT needed for me).

Speaking of AOUT:

You guys don't need continuous AOUT. It just has to send stuff in certain moments. So why not use 1 DAC and e.g. 16 or 32 buffers(buffers? sorry I'm not an electronic engineer :) ) which then fire off at the right moment? They will all send their stuff at once and that's what we want.

I was thinking a bit more about the shuffle stuff I've been talking about earlier.

If you want 128 ppqn resolution of shuffle (which as I understand it would translate to 128 parts/pulses per step), and each step should be arbitrarily settable to one of those parts (128 parts x e.g. 64 steps = 8192 positions total) you could use an easy algorithm. But first, why 128 ppqn? Because that could give fluid transitions between "no shuffle" and "max shuffle".

The algorithm would be as follows (please don't laugh):

(press play on sequencer)
$i=0

startpoint 1

$shuffle = read 8192 bits from $shuffle_storage[$k]      //$k = knob value, 0...127

startpoint 2
$f = read bit from $shuffle[$i]

if($f) then advance step

$i++
if knob value $k changes goto startpoint 1
else go to startpoint 2

of course that has to be synced to some timer somehow. I'm not an ee person so I wouldn't know how this works. However: 8192 bits x 128 knob positions = 1048576 bits! that's one megabit! that's way too much to store! or did I make a wrong calculation somewhere and multiply too much by too much....? :) Perhaps another idea to make shuffle patterns possible would be: 1. make a "max shuffle" pattern. You have 64 steps. Each of them can be moved by, for simplicity's sake, + or - 256 pulses (so + or - 2 steps max for some craziness). a possible algorithm to make this work would be:

(press play on tape)//sorry C128 times come to mind ;)

$shuffle = read table from memory
$step = 0


startpoint 1

$shuffle_max = $shuffle[$step]

$next_step_position_float = ($step * ppqn) - ($shuffle_max * $k/128) // $k = shuffle knob position, ppqn = 128 probably //(**)
$next_step_position = floor($next_step_position_float) // cuts everything after the decimal point and gives an integer
$waiting_time = $next_step_position - $old_step_position //(*)

wait for $waiting_time at 128 ppqn at the BPM we have set

advance step in sequencer //$step++ happens here

go to startpoint 1

pros: less memory taken up by shuffle table

cons:

- multiplication, division, usage of floats and rounding of floats all in one step. can PICs have floats? how great is the penalty?

- would have to find a way to check if steps aren't overlapping or handle them (if they are overlapping, i.e. we get a negative/zero on line (*) - we should just run the step at once perhaps? )

- shuffle happens linearly ( :( :( ) - non-linear shuffle would be the greatest stuff since the TR sequencer itself, to me. however perhaps it could be somehow emulated by usage of a gamma value for each step, so transition from 0 to max shuffle for that step could take upon some non-linear shapes. the line marked (**) would be more complicated then. If you don't understand what I mean by non-linear, think about it kinda like curved envelopes with the curvature settable.

flam could happen in a similar fashion. you could control it, from zero to max.. the transition would be e.g. adding volume (or rather velocity) to the further hits, or spreading them out (more frequent or less frequent hits). You could have 1, 2, ... 5, ... hits. As many as 128 ppqn would allow...

Whew! Hope I haven't bored you guys too much! Thanks for reading!

I know there's something I'm forgetting........... ;D

[TK.]

Good that I don't need to fullfill your personal wishlist here ;-)

The calculations for shuffle are not correct, you are especially mixing ppqn with the number of ticks between two steps, and you don't consider the required divider values when a sequencer is synchronized to MIDI clock (or when it sends MIDI clock). However, 0..15 ticks for shuffle is more than enough, the algorithm is already available in the MBSEQ application, therefore I think that I don't need to explain where the errors are... just listen to the MP3 at the MBSEQ page which demonstrates how the sequencer behaves when the shuffle value is slowly increased.

Best Regards, Thorsten.

[bdu]

I noticed no one has mentioned the 808's nifty A-A/B-B switch... damn that thing is handy.

[cheater]

What does that switch do, BDU? :)

And how do you use it? In what kind of situation does it come handy?

[TK.]

The A/B switch allows to chain two patterns - very useful :)

Best Regards, Thorsten.

[moogah]

It's probably about time I dropped in here  :)

I noticed no one has mentioned the 808's nifty A-A/B-B switch... damn that thing is handy.

Damn-Skippity-Straight it is!

Even more than the sound, I remember that feature most fondly.  While I was working on the clone I had originally tried to find similar 3 way toggle switches (A, A+B, B) to use as I think this made it even more "expressive" (if you will..) than buttons.  One of the few changes I want to make to the SEQ application's functionality for my 808 is to turn the morph feature into something more like this so that the uppercase and lowercase banks are treated as A and B variants which can be switched between, chained together or morphed using a pair of buttons and a pot (a horizontal slider might be the coolest option 8)). 

[mess]

(a horizontal slider might be the coolest option ).

I think such a fader would be a great feature  ;D

really nice idea  :)

[moogah]

Time to finish my .02

I had to stop and re-read this thread along with the WIKI page before giving my input as things have changed a bit since I last read.  So far I agree with just about everything people have said in this thread, even the stuff everybody agrees isn't part of a TR sequencer.  So, alot of this will be redundant, but I'm including a complete picture of my ideal TR:

-Standard 16 step editing:  We all know what this means.  And I feel the need to stress that adding more buttons to allow 32 editable steps is not a strict benefit.  It makes the interface more crowded and less easy to read.  I do like the idea of having greater scope for editing patterns tho, and I like the idea of two rows of different size buttons.  One could display current track and the other the instrument data or similar.  That would be pretty useful.  The software should be able to scale the number of buttons so that people can use as many as they want. 

-Instant hands on control of all parameteters, accessable in any mode of the instrument.  Despite what I'm doing for the 808 I think the best idea is to give every function it's own button.  Menus are not good for jamming.  Encoders don't "play" well IMO.  Buttons and toggle switches make the 808 great.  Even so I would generally stick to displaying one bar at a time, thats just me tho :)

-"Transparent" song mode.  Pattern play mode is good for jamming, but often falls short for complex sequences (you won't always have free hands).  Song mode on the other hand is usually too rigid for me.  I would propose wrapping pattern play mode inside song mode so that you still have total freedom to move around while the song is playing, and songmode will still be sure you make that tricky fill in to chorus part while you tweak the freq on another synth. 

-"Transparent" edit mode.  I don't ever want to press the stop button.  Seriously.    I should be able to go and edit a song while it is playing, and edit a pattern while the song is playing. 

-Pattern chaining need to be as simple and powerful as possible, all done on the fly without menus and encoders.

-Lots of syncronization options, in and out.  MIDI, DIN, individual triggers per instrument, clock trigger.  Everything.

-Global accent and individual accent per instrument.

-Flam, implemented like the 909

-Swing

-Variations and Fill patterns.  This is the main reason I want song mode to be transparent.

Now, how many features have been suggested that are not already in the V2 application, or in the V3 wishlist?  From working on my own version I've found that *everything* on my list of features was already implemented in the SEQ, it is just a matter of mapping the features to controls the way I like.