kokoon

can you post a few more details about that polysynth?

let me get this straight: you did this with linear slide mapped to an exponential table?

the third one sounds the best! what about slides from high to low? could you also post samples of that? maybe some shorter slides too (less freq difference) and some faster slides? some more bassy ones? ;)

so - the tables you posted that resulted in time differences (1 octave VS 3 octaves) - is the time difference because of inaccurancies in division (the inaccurancies are accumulative because you're using previous cycle's calculated frequency for the new one) or because of error in formula? i've tried to simulate that series in excel but didn't manage to finish it :) i suck at excel haha. but i'm here at seaside for weekend and i don't have anything else... hmmm i could with javascript... regarding your last solution - 5 semitones - what if the desired slide is less than 5 semitones? so you're saying rebirth (and probably tb-303) is doing the same? anyway - theoretically - is this statement correct - for 3x stronger slide (frequency range 3x larger) you need 3x faster slide? i mean - if the slides were linear (they're exponential) that would be correct... but is it still correct with exponential curves? you said it would sound better if the slide was faster from the beginning - what if we'd try with linear slide (constant addition per cycle)? have you already tried that? keep us informed! ;)

damn you're right. it doesn't match. :( now we can try to patch it up with a constant or something simple like that... but still something will have to be done about interrupted slides. i'll try to come up with a proper formula just to see how much more complicated it is.

yeah that's the page i meant. i found it too - but like TK said, there isn't anything there that helps us with this. actually no - the "constant slide time" rule would be violated in any case if you won't use the current frequency to calculate the rate modifier. do you know what i mean? each time a slide is started you calculate the "rate modifier" = max(curr_freq, target_freq)/min(curr_freq, target_freq) and use it. you shouldn't get curr_freq from last played note because the current frequency might be different if there's a slide already in progress. do you agree? oh and that *beeds* up there in my second post should be *needs* :D

i've no idea how such think works in analogue - it's obviously not a simple slew limiter or a lowpass filter - in order to get constant time it *beeds* to know source and target freq. i think :) i remember reading a detailed description of tb-303's slide somewhere. i'll see if i can find it. the example of interrupting the slide that you wrote - shouldn't the last slide from C-3 to D-3 be FASTER than normal in that case? anyway - i'd just store the last frequency in the process of sliding and treat that as the last pressed note before the slide. no need thanking me - i'm honored i can help you with this ;)

i've just started typing my thoughts on this and then deleted it realizing i was wrong. and i did it 3 times :) apparently it's not that easy to put it down mathematically. my next go at it: *a few more lines deleted* well apparently you'll have to add the frequency difference into the formula. let's see: one octave slide should last the same as two octave slide and 3 oct slide. so one octave slide's f1/f2=2 and two octave's is f1/f2=4 and three octave's f1/f2=8... for starters i'd just try adding the freq_high/freq_low to your equasion. something like current_frequency += current_frequency * rate_factor * freq_high/freq_low am i taking this way too lightly? :-\

zivjo vsi skupaj, ze nekaj casa moj MBSID stagnira nekje pred fazo izdelave front panela/ ohisja. ostali?

hey domestic! i'm also from slovenia! can't believe this finally happened :D contact me through slovenian forums, let's get that place moving!

i don't need scanning (DEmuxing) the matrix but muxing the midi note events onto the existing keyboard bus. i just need mini-in for the machine. i'll try to dig out the keyboard bus signals specification cause ATM i've actually no idea what exactly it looks like. ;)

that's great! i've sent him a mail. still, driving the synth directly from 1 CORE and 1 DOUT (or maybe AOUT?) would be really nice... that would really be a cheap polysix retrofit! the keyboard bus is 16 lines and the only question is how to mux the notes. and i'm sure i can find the info about this on the net. now if only there'd already be a midibox retrofit for some other keyboard matrix synth... you know of any?

hi guys. i'm getting a korg polysix and seeing it doesn't have a CV and GATE in - well i'm researching options to interface it somehow. i've found an interesting diy retrofit here http://www.angelfire.com/geek/srlabs/p6retro.html it utilizes a PIC16F84 and apparently it connects on the keyboard bus. i immediately thought about using a CORE and a DOUT module... ofcourse i could just make the kit as is described on the said page but i have no means of PCB production and also burning a 16x PIC would be hard... anyone?

yeah exacly. the SID drums are really cool but probably not for anyone. they probably would be considered by the majority as "bad quality" and non-realistic. but if you're after that - this is the real thing.

okay i did a little investigation and found out this ;) Shanghai Belling is apparently making the panasonic ICs' clones for a while now :-* Small Bear carries them http://www.smallbearelec.com/Search.bok?category=ICs+Delays+and+Echo the 3207 is 1024 stage which is probably unusable for echo but only for chorus and such. the 3208 is 2048 stage BBD (okay for short echo) there's also 3205 which is 4096 stage BBD and was probably the most common chip used in the vintage BBD boxes. i'll be making this: http://www.generalguitargadgets.com/index.php?option=content&task=view&id=140&Itemid=156 i've ordered 2x 3205 and 2x 3208 so i'll be making two boxes. generalguitargadgets are selling the pcbs too.

bassline = SID drums... i doubt you'll get acceptable drums from any of those 2... maybe "drums" with a bit of imagination :)

hello. first: single height unit rack will be a bit hard i think - it may work though but you might have to solder a few tall caps horizontally. second: i'd absolutely recommend at least the basic control panel (LCD + 5 buttons + encoder) to be able to control the synth completely without the pc. then i'd go with (considering you wanna stuff it all into 1H rack) filter controls (2 encoders) + combined 5 pots for envelope generators for DCA and for custom envelope. if there's space for 2 more encoders i'd put (switchable for all 6 of them) LFO controls there too. then, combined with the basic CP i think you have a pretty good control set. third: one SID chip provides you with a mono output but it has 3 oscillators which are output mixed. that means three "layers" of sounds at the same time. can be three different single - layer sounds or combined. or you can use them for polyphony. so you can play (3-note) chords. any additional SID basically means +3 sounds. i think you'd be happy with four SIDs and it's really not that much of an extra expense. which leads us to... fourth: rack enclosings can be expensive. if you intend to buy it pre-made and then the front-panel too then you'll surely go over 200 euro. other stuff is cheap. or at least can be found cheap.

also DK-80 has two filters and POLY-800 only has one (that's right, ONE filter for all 8 voices...) also - DK-80 has 12 voices. the expander though (what you have) is really similar to EX-800. but POLY-800 (mk1) even had no sysex for loading patches...

thanks alot! i'll check it out when i get it back (a friend has it now, we share it) but i really doubt. MAYBE the EX-800. but poly no way. still i've came up with an idea - let's say poly isn't midi controllable - i could still build in encoders for each parameter and when each encoder is moved a signal is first sent to set the parameter number. i'd need a simple microprocessor for that and a few lines of code (map each encoder to it's parameter number)... still, i'll go first with the encoder instead of up/down buttons ;)

hmm well good luck cause that's what i've been doing for a week now :) still i think your clone is not exactly a "clone" but a more advanced synth. anyway - i'd be ecstatic if you found anything about poly-800 midi implementation.

well thanks for advice. not my thing though :) i'm still planning on trying this ;)

i know about the moogslayer mod and it's the first thing i'll do. then i'll have a try with this encoder idea cause those buttons are pure pish. about the midi controllers - i've done quite a lot of investigating and as far as i can tell there is almost nothing that can be controlled via midi cc. except "modulation". maybe your clone is different. however - i recently found out that the mk2 version of poly-800 had the option of dumping and loading patches via sysex. still nothing could be changed in realtime. but now when i think about it again... i remember an article about implanting an EX-800 eprom into poly-800 to achieve some sort of midi controllabilty with the sacrifice of non-functional keyboard... hmm what exactly do you know it's possible via midi? if EX-800 really allows changing of ALL parameters then that's just freaking awesome and i'll be making a programmer box for sure!

uh okay... i forgot about the release. the delays complicate the thing a bit... still - i'll have a look at the code. thanks alot for the detailed instructions. obviously it's not a lot of code to add... i'll have a look!

okay guys sorry i found it - it's called quadrature decoder and there's plenty on the web. funny, the first one i found refers to midibox :D http://users.tkk.fi/~jwagner/electr/rotary-enc/rotdec.jpg

i am clueless about where to start looking for this on the web. obviously i need some sort of "decoder". do i need a microprocessor like the PIC? the decoding of the encoder is pretty trivial (in terms of logic)... maybe a bunch of AND gates would do it... any recommendations where to start?