e-licktronic Forum

obviously there's a lot of things needed just to recode the basic foundation for a new sequencer
- get rid of the arduino stuff (well, that's me, i don't want to use that stuff)
- start a new project, figure out how to initialize the cpu IO (this can be borrowed from the existing FW)
- code for dealing with shift-registers (for LEDs and buttons) - i already got these from my x0x FW so i can just use em
- code for dealing with the i2c eeprom - this i'd have to figure out, since i2c isn't my fav
- code for interrupt-driven, buffered MIDI input output - i can borrow that from my x0x FW too
- figure out how the cpu controls the actual instruments

that's gonna have to be done regardless of what direction the actual sequencer will go (authentic or not)
from there, it's all specific
one very important thing to figure out is the pattern structure
that depends on how the sequencer works, and that requires chosing what features we wanna have in it

i've done an approximation of the 303 sequencer, without actually having seen a real 303
so i know what it takes to do it ... it's basically "black box" modeling
and it can be done, with enough effort, patience, and collaboration

to do it for the 808, it'll take:
- someone who *knows* the behavior of the 808, to answer all kinds of questions, both in the big picture but also about small details
- someone who has an 808 and can perform specific tests (black box modelling, remember? )
- figure out what are the differences between the 808 and the yocto and whether that would cause a problem with the sequencer approximation ...
- decide what extra features can be squeezed into the yocto without destroying the authenticity of the 808 sequencer, and without those new features looking like aliens in the workflow
- figure out the pattern structure, and any other memory structures (tracks? )

once these things are solved we can begin building the big picture for how the interface should look like (a diagram will help here, or just anything that looks like a map, or even plain text)
and at that point, things will be very clear and the sequencer can be implemented

if we decide not to stick with the original sequencer too much - things are slightly easier
- we don't need someone with deep knowlage of the 808
- we don't need someone who has an 808
but we still need to decide what kind of features we wanna have, because the memory structure depends on that, as well as making the diagram/map of the different features

i've learnt something about sequencers
- they're harder to design that you'd think
- from the user POV they can be more important than the actual synthesizer they control, because an annoying sequencer workflow will not encourage you to use the instrument too often
- if you decide to approximate an existing sequencer - most of the design decisions have already been taken by the original designers, so you're safe as long as you stick to it and don't break anything (i learned that the hard way)
- if you decide to roll your own sequencer - you have to make all those design decisions

...that's just some thoughts

Hi antto - thanks for adding information we'd all have to think about.
I guess that if we stick to the original sequencer model, it gets easier and faster to develop a new firmware. Do you think that it's possible to add our "desires" (features) to that as well?

I mean, my main concern is to get the "bugs" fixed, the ones who are annoying me (and others) as a user.
You said it already: an annoying sequencer workflow leads to not using that instrument at all. And this is what I'm experiencing actually: the lack of those couple of features I'd like to have (SysEx dump is one of them) is not encouraging me to use the Yocto (I don't want to simply play/trigger its sounds from another sequencer).

I'm glad to see that you want to do something about it and I'm still available for testing. Sorry I can't be more helpful (no TR-808 in my house for example).

BR,
F.

FlavioB wrote:Hi antto - thanks for adding information we'd all have to think about.
I guess that if we stick to the original sequencer model, it gets easier and faster to develop a new firmware.

the easy aspect is that most of the workflow/design decisions have already been taken by the authors of the original sequencer
so if you can keep these (if the difference between the yocto and the 808 don't stop you from sticking to the original) and if the original sequencer is good - then you know from the start that you will get that same workflow and it's gonna be good

as an example:
the x0xb0x is missing one button from the 303, has one extra button (on the tempo encoder), has all the required LEDs plus more, has more banks/modes on the selectors, has more memory, has MIDI
so one of the big problems i had was to figure out how to deal with the missing button
other than that, i sticked to the original
the actual black box modelling is hard, i've rewritten the thing a number of times till i get it "right"
i've started somewhere in 2009 with a plugin which had a completely non-authentic sequencer (i basically made the sequencer how i liked it) ... and it kinda sux
somewhere in 2010 (iirc) i bought a x0xb0x, and i began writing an attempt to clone the 303 sequencer, but i decided to roll my own pattern format, with some extensions ... this failed (and progress also stopped due to lack of space on the cpu)
later i rewrote the sequencer in my plugin, to give it an authentic 303 sequencer, i had the luxury of having the exact same buttons (unlike the x0xb0x) but also the additional LEDs and anything i want to put
this is where i really learned lots about the 303 sequencer, i've read the manual, we've spent months talking on IRC with the guys who actually have 303s and were answering my questions, doing specific tests
at the end of the day, i figured i'm missing something very important.. selecting and editing chains of patterns, so i had to make fundamental changes which broke many things.. but i got it working
a bigger cpu for the x0xb0x became a reality after that, so i went to give it the authentic 303 sequencer too, this time i knew 90% of the stuff i have to put, because i already had them in the plugin
somewhere at that point i figured that i've gotten the pattern format wrong, again... so it was too late for my plugin, but i fixed that in my last x0x FW

anyways, this took years, but the 303 sequencer is very weird and the whole 303 is burried in myths, and i was learning most of the things, aaaand i was making mistakes
if i have to re-write the 303 sequencer approximation right now - i know many wrong paths which i would simply avoid and that will save piles of time

Do you think that it's possible to add our "desires" (features) to that as well?

there's many things that are possible, the cpu is fast and has quite some flash space and RAM
the problem is more about how to access these features
i am already experiencing the lack of buttons on the x0xb0x, i've actually added a drum sequencer to it, just because i wanted to see if i can code one, and it works... however, there's no way to actually use both the bassline and the drum sequencer at the same time because both of them consume pretty much all of the buttons and LEDs, so i removed it
here's some video of it: https://www.youtube.com/watch?v=y1r1ZjUlZfQ
it had 12 instruments, individual accents, only tap-write mode because i don't have a row of 16 buttons, and it generates midi notes, of course, driving the korg ES-1

I mean, my main concern is to get the "bugs" fixed, the ones who are annoying me (and others) as a user.
You said it already: an annoying sequencer workflow leads to not using that instrument at all. And this is what I'm experiencing actually: the lack of those couple of features I'd like to have (SysEx dump is one of them) is not encouraging me to use the Yocto (I don't want to simply play/trigger its sounds from another sequencer).

the current yocto FW really looks unfinished, reminds me of the x0xb0x stock FW which was certainly unfinished because it was reaching the end of the available flash space
there's bugs surely, annoying ones, but i am talking about writing a completely new FW here, this means it won't have much to do with the current FW (but nothing stops it from having its own bugs)
there's many features i have in my x0x FW which i would put into the yocto (if possible, since these features require access (button combos) and feedback (LED indication))
to get an idea what my x0x FW has, you can check its manual
http://antonsavov.net/cms/projects/n0nx0x2/manual.html
i saw some wishes in the other thread, i see features which i have in my x0x FW like the ability to start/stop independantly from the master (when slaved) and then to (re-)start on the bar (Delayed-Start)
i certainly want to have those in the yocto, because they are very useful

okay, i just saw that there will be a yocto v2.0 PCB with a completely new sequencer.. that explains the situation
supposedly it'll have a similar sequencer to the NAVA
i hope they've ditched the arduino crap this time

Imho, the whole difference between writing a drum sequencer for this or a sequencer for something like the 303 is that it doesn't have to be a 100% faithful clone of the original sequencer to feel "right". There's nothing really super special about the 808 sequencer, it's just a typical TR-x0x style sequencer with some "unique" features.

Lets have a look at it (correct me if I make mistakes, it's been 10 years since I played a real 808):
- 32 patterns which can be up to 32 steps (using 1st part and 2nd part)
- tracks of up to 768 measures (or max. 12x64 measures, similar to how tracks on the 303 can span multiple slots)
- Basic-variation: like on the 303 there's a pattern A and pattern B section, however there's an AB option here to automatically play back A followed by B. (allowing 64 step patterns)
- Intro / Fill-in: plays a special pattern and returns to the pattern that was playing. This can happen automatic (every 16/12/8/4/2 measures) or manually
- Step and Tap entry modes

The I/F and basic variation features are nice performance tools, but not something that can't be done in another way.. Personally I really don't care to have exact reproductions of these functionalities.. If we can chain patterns, we can get most of the same thing.. Minus the auto fill in. If we can think of a usable way to do 64 step patterns, that would be neat too, but chaining seems to be very straight forward.

As antto already said, we really need to get rid of the sync mode stuff because its confusing and hard to use. E.g. when stopping the external clock in pattern edit mode, you have a problem in the current firmware

We currently have the following on the mode switch:
1) Pattern Mode
2) Pattern Mode (dinsync)
3) Pattern Mode (midi sync)
4) Pattern EDIT Mode
5) Track Mode
6) Track Mode (dinsync)
7) Track Mode (midi sync)
8) Track EDIT Mode
9) Expander
10) n.c.
11) n.c.
12) Initialize EEprom
13) n.c.
14) Clear pattern
15) Paste pattern
16) Copy pattern

This could be changed to:
1) Settings
2) Pattern Play
3) Pattern Step Edit
4) Pattern Tap Edit (we could simplify button combo's with tap mode in a different menu, it's similar to 707, 909, ..)
5) Track Play
6) Track Edit
7) Track Record (record tracks in realtime, like in n0nx0x2)
8) ??
9) Expander
10..16) ??

Not sure what the other modes should be.. I believe we should limit ourselves to the bare basics and go from there.

As for features:
- I also agree with the proposed delayed start feature (as seen in n0nx0x2). This could be a combo of shift+start.
- Don't really care for shuffle, but wouldn't mind if its in there.. Shift+Tempo (click) would be an option
- Clone the tempo knob behaviour of n0nx0X
- the "freeze frame" feature from n0nx0x2 would be awesome with drums, however it would be nice to have accelerated freezes (32th notes) and to limit freezes to one or more sounds.. The "Roll" button would be perfect for this, perhaps in combo with shift
- We might need to change the way pattern length is currently set. (shift alone will conflict + it would be nice to be able to use the encoder for it like in n0nx0x2)

Hmm thats it for now. Comments welcome. I'm willing to help push this forward

Hi all - thanks to antto and rv0 for your extensive contributions to this thread: it's getting interesting!
Now, I can't add too much here - I'm an end user with some wishes and desires about missing things/features/functions on the Yocto, so my main concern and hope is to get those things "fixed".

Anyway, I do agree with you both about changing the selection switch function layout and the one proposed by rv0 seems to pretty hit it. Still, I wouldn't want to lose "Initialize EEPROM" and all the "copy/paste/clear pattern" functions neither.

Also, please don't forget SysEx pattern dump!

I'm here for testing, if needed.

Ah, and BTW: what's new with PCB 2.0 in fact?

BR,
F.

FlavioB wrote: Anyway, I do agree with you both about changing the selection switch function layout and the one proposed by rv0 seems to pretty hit it. Still, I wouldn't want to lose "Initialize EEPROM" and all the "copy/paste/clear pattern" functions neither.

Sure. The only reason why I left them out there is because maybe we'll need the slots for other things and think of a better way to implement copy/paste/clear on the current UI.
I wanted to define basics as the rest is pretty much open for discussion.

FlavioB wrote: Also, please don't forget SysEx pattern dump!

Sure, that could fill one of the many empty slots of the selector switch.
If we have lots of spare slots, we could stretch it as far as having 4 slots for it:
- Pattern Dump
- Pattern Receive
- EEPROM Dump
- EEPROM Receive
(basically, 2 modes to dump and receive individual patterns, 2 modes to dump and receive entire memory)

FlavioB wrote: Ah, and BTW: what's new with PCB 2.0 in fact?

the only public info about it afaik is here: viewtopic.php?f=16&t=1061



I can think of some more exotic things to add, but it seems more productive to keep it simple for now

OK, great. So, when do we start?

Hi guys!
Nothing new here it seems...
What about the "official" firmware development? And also, what about this "new idea" discussed in this thread?
BR,
Flavio.