bugfight

indeed, else i would not be hankerin for a midi version. i have 2 in fact. as i said before, with the edp you set the beat length ahead of time with the eighths-per-cycle parameter. the tempo is then derived from the cycle time. you can go the other way as well, setting bpm ahead of time and then the device executes multiply during initial record. one or the other is required for synch, and for the awesome quantized functions in the edp. don't worry if you are not a coder, there are plenty around here and design ideas/testing are valuable. otoh, the device tk linked may suit you nicely if you don't want the advanced features of the edp yes midi volume might fake feedback settings, but midi devices are notoriously bad about treating it their own way. we can also use note velocity to fake the feedback, lowering it each repeat, upon reaching zero the notes would be removed etc. again different devices treat this very differently, for example there can be a great jump from vel=1 to vel=0. this would not work at all for pads which is one of my favorite things to do with the edp, start record, fade in some sus chord or likesuchas, end record with overdub and fade out/ or change gradually, esp with feedback at 80% or so, lowering feedback if it gets too dense, moving to 100% if the bed is 'finished'

looks like an interesting little guy, but it's nothing like the edp...

in order to synch, you will have to specify the beat length or the tempo (this is how the edp works too, with eighths-per-cycle and bpm) there will also be ram limitations to deal with, but some simplifications can help, like only working with midi notes, or a limited number of layers, limited time resolution etc... for a midi edp, two hurdles come to mind immediately: - midi notes have note-on and note-off pairs. overlapping these will result in incorrect output. the data structures will have to take care to keep these pairs together and avoid overlapping. overdubbing will have to be treated with special care. starting or ending a record or overdub with notes still held will also have to be dealt with... - for feedback < 100% (a very important feature on the edp) there is no direct corollary with midi. it could be that cc can be used to fake it, but this will probably behave differently for different midi devices. i don't expect this to be of interest to a large number of midiboxers, but i do like the idea and have long intended to work on it, so will be willing to help out if others do want to get involved.

got mine last week, thanks mucho!

heya, "Agent86", hows about hooking me up with 99? teh chat sure does miss dw... among others...

abracapocus! rise ye olde thread... here is my latest attempt to move towards the william's ideal. and where are the pics of all the young d00dz labs?

woah, real instruments, is that allowed? hehe very nice!

muahahhahaha wilba thought the world would end so offered up his toys... hmmm taunting the mighty queue in this fashion might end the world after all...

if you order them from a pcb factory, be sure to avoid HASL on the pcb contacts, it oxidizes rapidly and the switches will not work properly. bare copper is a similar problem. i had some success using a chemical plating product called cool-amp which is pretty good for diy pcbs. iirc the sparkfun silicone button pcbs use a silver surface. i think the best idea is to use ENIG or gold leaf on the contacts, but i lost interest in the sparkfun blm before testing this...

hi midibox newbie, this is not an ecommerce site. you are not our customer. your post is coming off as self-entitled and rude, if you did not intend this, i suggest taking a different approach...

wow, i'm late to this party... this looks fantastic so far. 2 cents is still not very many euros, and i have a tendency to generalize applications too far, but i will just bring up a few ideas that may already be too generalized: 1) starting phase for oscillators, this would allow for 4 phase and 3 phase functions (ie solina chorus). it might be enough to just allow 12 start points, which allows exact division by 2,3,4, and 6, but since we are in midi land it might make sense to use 128 ([0, 43, 86] would probably be indistinguishable from "true" 3-phase, certainly so for a chorus effect) 2) constants could be allowed as inputs to mod<n>, maybe even named constants (ex. CVMIN, CVMAX, CVMID) 3) why limit mod values to 2 inputs with single math operators? maybe i mistake the meaning of the names mod<n>, i'm assuming they relate to the modmatrix on the sid, which i enjoy playing with a lot. it seems like it would be better to at least have one layer of indirection, having a variables table with these operators and then simply assign a var<n> or input<n> to mod<n>. this would at least allow for more complex operations, though it can quickly become unwieldy and the size of the variables table may be an issue... an example: one operation that might be commonly used is to scale an input to a range, ie "take input 1 and scale it to 1v-2v"). this is a 3 input function, so supporting it with a built in function would still require a change to the interface. it would be possible with one layer of indirection but would require several variable table positions to implement. the best thing for me would be an expression evaluator, but that's probably not practical on this platform. ok so not a very concrete suggestion and based on some assumptions, but something to consider... 4) i really like sneakthiefs idea for an interface to the quantizer, as it more closely relates to how i would think of the various modes, esp if they can be played on the keyboard and captured, ex by a footswitch funtion that starts grabbing notes when pressed down and calculates the pitch set when released... 5) this brings up something i have resisted mentioning about the force-to-scale function of the mbseq, since by the time i got interested in the mbseq it had already been in use for some time. it may be that this should only be considered for a separate quantizer module, but since this is a new application it might be worth considering now. the list of scales includes many sets that are the same set of intervals with a different starting note (modes). most musicians i know who think modally think of these as the same scale, or more specifically as 2 things: scale and mode. the problem with using names for each mode is that there are many useful modes that have not been named, or that have more than one name. a more general approach is to name a normalized form of the set (ex. harmonic minor) and then use a number from 1-8 to indicate the mode (0-7 in programmereze). the downside is that you waste some bits because there are many scales that only have a few modes and the other numbers are either repeated (ex. the diminished scale only has 2) or meaningless (pentatonic mode 7??) and mode 8 is meaningless for most scales hehe this leads to the notion of implementing other tuning systems than 12 tone equal temperament, esp since many of the included named scales don't really exist in that domain. but wouldn't it be nice to synthesize a baroque piece in just intonation, or hear bach's well tempered clavier in the tuning system he used? then there are more modern microtonal systems... ok this is already into deep outer space, back to lurk mode...