Re: Is still someting going on here? Any dev-activity?
Posted: Sep 9th, '16, 22:50
i've been thinking about writing a sequencer for the yocto
i checked the current FW source code, wtf.. arduino? i don't want to learn this uino thing right now
a better option would be to start from zero
there are some things which i don't like, like:
- the eeprom being i2c (which is slow, plus i'm not familiar with that interface)
- the button debouncing is bad/broken
- the way the sync mode (internal/dinsync/midisync) is put on the function selector like with the x0xb0x stock FW this is annoying
these are somewhat fixable - there's a 16KB RAM on this chip, so (i haven't actually calculated it but) most of the sequencer memory can be thrown into the RAM and periodically stored in the eeprom, button debouncing can be fixed, the function selector could be reorganized and sync mode can be a global setting
unfortunately there are a few things which are harder to overcome:
- the lack of buttons
- a fast way to reflash the chip as part of the developement process (frequent recompilation and testing)
since the yocto has only MIDI as a serial communication, i assume the bootloader is flashed via sysex
and i guess it's borrowed from one of the existing places which provide a sysex-enabled avr bootloader, i've heard bad things about one of those, i bet it's not buffered and packets break unless you intentionally slow down the sysex transmit, as if midi isn't already slow enough for this job
i've put sysex onto an stk500v2-based avr bootloader already as part of another project, and it's buffered there, doesn't require special configuration, the data can be sent without additional pauses/delays
but changing the bootloader is practically not an option for those who already have the chips (a programmer is required)
-------------------------
so there are a few options i can think of
- i could (since i have a programmer) change the bootloader on mine, just to make it easier (if possible) to reflash frequently
- rewrite the thing in C or maybe C++ but minus those uino libraries
- reorganize the function selector and maybe the roles of some buttons
--- remove the sync mode from the selector
- abstract away the scary ugliness of the i2c eeprom
however, given the very limited amount of buttons, i have no real idea how to make accessible all of the functionality i'd like to put into a drum sequencer
to solve this, what's needed is a carefully crafted plan of features and functionalities that should be featured in this thing, which requires some tough decisions to be made, dillemas and compromises
i'm not familiar with the 808 sequencer, and i haven't even used the yocto sequencer too much yet, i've only figured out how to make a pattern, and use the mute function in pattern-play mode
so if anyone has time to think about a detailed plan of features and modes it'll be a good starting point
the stuff i'd personally like to have in it are:
- live pattern recording by tapping the instrument buttons
- shuffle
i checked the current FW source code, wtf.. arduino? i don't want to learn this uino thing right now
a better option would be to start from zero
there are some things which i don't like, like:
- the eeprom being i2c (which is slow, plus i'm not familiar with that interface)
- the button debouncing is bad/broken
- the way the sync mode (internal/dinsync/midisync) is put on the function selector like with the x0xb0x stock FW this is annoying
these are somewhat fixable - there's a 16KB RAM on this chip, so (i haven't actually calculated it but) most of the sequencer memory can be thrown into the RAM and periodically stored in the eeprom, button debouncing can be fixed, the function selector could be reorganized and sync mode can be a global setting
unfortunately there are a few things which are harder to overcome:
- the lack of buttons
- a fast way to reflash the chip as part of the developement process (frequent recompilation and testing)
since the yocto has only MIDI as a serial communication, i assume the bootloader is flashed via sysex
and i guess it's borrowed from one of the existing places which provide a sysex-enabled avr bootloader, i've heard bad things about one of those, i bet it's not buffered and packets break unless you intentionally slow down the sysex transmit, as if midi isn't already slow enough for this job
i've put sysex onto an stk500v2-based avr bootloader already as part of another project, and it's buffered there, doesn't require special configuration, the data can be sent without additional pauses/delays
but changing the bootloader is practically not an option for those who already have the chips (a programmer is required)
-------------------------
so there are a few options i can think of
- i could (since i have a programmer) change the bootloader on mine, just to make it easier (if possible) to reflash frequently
- rewrite the thing in C or maybe C++ but minus those uino libraries
- reorganize the function selector and maybe the roles of some buttons
--- remove the sync mode from the selector
- abstract away the scary ugliness of the i2c eeprom
however, given the very limited amount of buttons, i have no real idea how to make accessible all of the functionality i'd like to put into a drum sequencer
to solve this, what's needed is a carefully crafted plan of features and functionalities that should be featured in this thing, which requires some tough decisions to be made, dillemas and compromises
i'm not familiar with the 808 sequencer, and i haven't even used the yocto sequencer too much yet, i've only figured out how to make a pattern, and use the mute function in pattern-play mode
so if anyone has time to think about a detailed plan of features and modes it'll be a good starting point
the stuff i'd personally like to have in it are:
- live pattern recording by tapping the instrument buttons
- shuffle