monome / aleph Goto Github PK

software timer class is bloated and modularity sucks. avr32 OS and applications should have separate timer lists, and these can be hardcoded.

a scene currently stores the name of its module. additionally, we should have default scenes associated with each module and the option to load the default scene from the modules page in bees.

need voice-allocation module for polysynth. should probably design monosynth with an eye towards abstraction.

finish a working monosynth module. wavetable oscillator access works well but needs working envelopes, filters, waveshape generation
depends on : issue #9

need a mechanism to poll operators from TC as necessary

finish implementing bees menu commands.
here is the full list from the guide.

for bugs with implemented commands, search for related issues and/or make new ones.

INPUTS:

• SW0: STORE: store current value in current preset
• SW1: INC/EXC: toggle inclusion of this input in current preset management
• SW2: CLEAR: disconnect everything from this input
• ALT0: GATHER: go to modal page with only the outputs connected to this input
• ALT1: SHOW/HIDE: toggle inclusion of this input in play-mode listing
• ALT2: FILT/ALL: show only play-enabled inputs in this list, or show all (default).
• ALT + ENC0: select preset for recall + edit
• ENC2: --- change parameter value, slow
• ENC3: --- change parameter vlaue, fast

ROUTING:

• SW0: STORE: store current routing in current preset
• SW1: INC/EXC: toggle inclusion of this routing in current preset
• SW2: CLEAR: disconnect
• ALT0: FOLLOW: select this output's target on inputs page, and go there
• ALT1: SPLIT: create a SPLIT operator and connect to its first input.
  if operator was already connected,
  connect the split's output to its former target.
  select the other split output.
• ENC3: --- scroll target input

PRESETS:

• SW0: STORE: store all nodes at this preset.
• SW1: RECALL: overwrite all preset-included nodes with preset,
  update inclusion for next recall.
• SW2: COPY/OK: begin copy / confirm and finish copy.
• SW3: DEFAULT: store current settings as default

SCENES:

• SW0: STORE: store current state of network to scene name.
  if the name has been edited, a new file will be created.
• SW1: RECALL: load scene (halts network processing and may make noise).
• SW2: COPY/OK: begin copy / confirm and finish copy.
• ALT0: DEFAULT: store current settings as default
• ALT2: CLEAR/OK: clear the current scene

OPERATORS:

• SW0: INPUTS: select this op's inputs on ins page, and go there.
• SW1: OUTPUTS: select this op's outputs on outs page, and go there.
• SW2: CREATE: add a new operator of selected type.
• SW3: PAGE/LIST: toggle op-specific subpage
• ENC3: --- select operator type for creation.

MODULES:

• SW0: LOAD: load audio module from sdcard.
• SW1: DEFAULT: write audio module to internal memory for startup.

get your OOP act together and write custom copy methods for preset_t, scene_t, ctlnet_t, and whatever other big data classes are being blindly memcpy'd with impunity all over the dang place.

midi driver works at a low level but needs operators in bees and management in network

ASR is sort of broken. coefficient calculation is slow enough to disrupt audio. might as well use a lowpass filter.

have a detailed plan of how production will happen.

how to play factory. every step.

fonts and glyphs should probably be application-specific.
provide raw access to pixels and some compositing methods.

structures such as menu pages should be able to keep their own graphics buffers, rendering new text only as needed.

simple functionality

make a basic drum synth module.

• noise sources
• filters
• oscillators
• envelopes

assemble pcbs, check physical fit, etc

photos
text
diagram
video

the event handling system sucks.
should have separate queues for periodic system events (triggered from timers and handled by OS) and for events that are initiated from UI and handled by application.
should probably use arrays of function pointers that can be dynamically re-assigned by application.

rlc

the source files for pages are a mess and should at least be separated. pages should never be using a big case statement on UI.
see issue #15

avr32 bootloader should include some test facilities.

• RAM
• cv loopback
• audio
• screen
• footswitches
• buttons
• encoders
• usb connections (aleph as host)
• serial connections (aleph as device)

articulate and document a consistent code formatting/naming style and suggested worklfow (e.g. where and when to branch/merge/push.)

not to mention, applying agreed-upon styles to existing codebase...

quotes remain:
top plate
pcb production
pcb assembly
general assembly
packaging
power supply

google checkout is going away.

need to move to a new processor.

still seeing occasional unsuccessful blackfin boots. the system can work around them but i fear for the lifespan of the chip if it is booted from garbage. (we have seen that out-of-spec clock division settings will burn out the dsp, for example.)

for starters, we can checksum the .ldr data to see if there is corruption from sdcard.

in extremity, we could store each blackin programs as .hex and checksum each entry as we do with avr32 firmware. the downside is potentially a lot of computation time when loading a new dsp.

it seems unlikely but possible that the corruption is in SPI; checksum mismatch before that would suggest not.

improve documentation of programming

• toolchain setup
• API descriptions
• annotated examples

must also buy/allocate a VID/PID

http://www.mcselec.com/index.php?page=shop.product_details&flypage=shop.flypage&product_id=92&option=com_phpshop&Itemid=1

python? x-platform ease preferred.

libusb?

need a custom die cut box so we're not using filler material

a couple local referrals:

http://www.rdacontainer.com/Contact.htm
http://www.orconind.com/about.php

re-test CV output dac drivers. integrate this with the blackfin core. expose aleph parameters for output values.

revise build system

translate between binary scene files and XML or JSON or whatever the web kids are using.
alternatively, additionally, or relatedly: design a means of transmitting edits (+ performance?) over serial ports.

need an abstract mechanism to embed some descriptive text in a firmware .hex file, and probably to assign a default audio module.

audio buffers need double-precision or float indexing for subsample access. 32.32 indexing is present but broken.

loading monome op splatters weird shit into memory.
possible null function pointer.
might be better idea to store manager classes in the network data so their state is saved in scene.

eventually we should have ADSR and maybe others.

make a simpler app than bees to demonstrate easy use of avr32 OS layer.
loop pedal would be a good candidate.

1. viola and mic input, echo patch, foot pedals, analog insert path (filter?)
2. eurorack and gamepad, bees sequencer or something
3. aleph with usb midi keyboard playing polyphonic synth
4. monome grid with aleph drum machine

operator to time gesture inputs

we should be able to drastically improve blackfin performance with a well-considered control rate implementation.
will also let us get away with more in the numerical-precision department when e.g. applying control-rate filters.

labeling, readability, comments, organization, part numbering

this got barfed up at some point since i switched to testing on mext and changed a bunch of stuff

setting parameters really fast can result in what seems like breakage of the blackfin SPI state machine.