bugfight Posted January 7, 2012 Report Share Posted January 7, 2012 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... Quote Link to comment Share on other sites More sharing options...
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.