Open303 - open source 303 emulation project - collaborators wanted

[Music Engineer]

kunn said it is modeled after the TB-303 filter, it's another ladder, yet different transfere function

is the info about that here in this thread? i guess so, but i'd like to be sure before sifting through some 40 pages

there is some slight difference, this is where i started asking wether a digital implementation of an analog filter would have the same phase response or not

generally, both, magnitude- and phase-responses will differ slightly from the analog prototype, in particular near the Nyquist frequency. how this abberation will exactly look like depends on the method how the discretization was done (bilinear, impulse invariant, etc.). however, if there's feedback around the filter, the phase response in the feedback path will have an added linear phase term due to the unit delay (...and this linear phase term is exactly, what my moog-tuning formulas compensate for, btw.)

[antto]

btw, where did you get this plot-thing? could it be a oscilloscope?
i seriously need a good VST oscilloscope, grrrr
i hate that i can't just *code* my own

[Music Engineer]

btw, where did you get this plot-thing? could it be a oscilloscope?
i seriously need a good VST oscilloscope, grrrr
i hate that i can't just *code* my own

check my website (see my sig)...btw.: i thought you actually can code, how else are you implementing all this stuff? i mean, yeah, i know that SE is a graphic modular environment but i was under the impression that you are writing your own modules. no?

[antto]

yes, but in order to write an oscilloscope, i need to mess with:
time (probably timers or something)
threads?
GDI (i don't need fancy stuff, SetPixelV() works)
and i am really poor in these
i have messed with GDI, but if i open up an emtpy C++ project, i just cannot make myself a window, and start drawing in it (GDI)
i hate it, but that's it
this is why i use mIRC to plot stuff
i coded my own modules - yeah, but it's all DSP-side, sequencer, oscillators, blah-blah, i did the GUI using SynthEdit's standart GUI modules, which is very easy (tho, a little restrictive, since i know what i could do if i had some decent knowlage around winapi)
anyway this is not on topic actually

yeah, kunn has posted both "versions" of his filter, one with all nonlinearities, and the cheaper one, with only 1 nonlinearity

i'll paste a link to that post
there was a little discussion around it, which might make sence to you ;]

EDIT: http://www.kvraudio.com/forum/viewtopic ... 80#3794880 <- found

[Music Engineer]

you may want to have a look at JUCE:

www.rawmaterialsoftware.com

it frees you from worrying about stuff like WinAPI and GDI and whatever. it's powerful, easy to use and you can also learn a lot from it about good coding practices, design patterns and stuff - i use it for just about everything

EDIT: http://www.kvraudio.com/forum/viewtopic ... 80#3794880 <- found

aha, thanks - i'll try it. the 'a'-coefficient is the same as in the moog filter there?

[kunn]

aha, thanks - i'll try it. the 'a'-coefficient is the same as in the moog filter there?

it depends. with Huovilainen's filter - yes (tho it uses g). looking at your moog filter paper then a=a1+1, i guess. it is equivalent to If/(4*C*Vt) in analog.

the cutoff response (to a) is very different compared to moog. in a moog filter the effective cutoff fc=a always. in a tb-303 fc=2*a when k=0 and fc=sqrt(2)*a when k=17.

[antto]

gonna check juce..

kunn gave me some tuning data and i did these approximitations, which are very good, also the gain-compensation for resonance at high cutoffs:

double fx = o * 0.25 * coeff_sqrt05;
// o is omega, 0.25 because of 4x oversampling, coeff_sqrt05 is sqrt(0.5)
a0 = (0.00045522346 + 6.1922189 * fx) / (1.0 + 12.358354 * fx + 4.4156345 * (fx * fx));
k = fx*(fx*(fx*(fx*(fx*(fx+7198.6997)-5837.7917)-476.47308)+614.95611)+213.87126)+16.998792;

double gc = k * 0.058823529411764705882352941176471; // 17 reciprocal
gc = (gc - 1.0) * r + 1.0; // R is 0 to 1.0 ;]
gc = (gc * (1.0 + r));

k = k * r; // K is ready now

<filter>
.. stage4 ... out = y4 * gc; // gc doesn't affect the feedack or anything

now, i did changed the K coefficient a little, to be able to have another knob control the "ground level" for the resonance, while still r=1 equals full-feedback

double rg = <knob_val>; // resonance ground?! ;P~
r = r * (1.0 - rg) + rg;
k = r * k; // K is ready

[Music Engineer]

it depends. with Huovilainen's filter - yes (tho it uses g). looking at your moog filter paper then a=a1+1, i guess.

you are right - it is what i call 'b0' in my paper (well, at least, i tried it this way and it works). thanks for clarification.

the cutoff response (to a) is very different compared to moog. in a moog filter the effective cutoff fc=a always. in a tb-303 fc=2*a when k=0 and fc=sqrt(2)*a when k=17

interesting. and as you already pointed out earlier, the tuning and feedback gain has to be tweaked - using my moog-filter tuning and feedback equations (multiplying k by 17/4), the resonant frequency and self-oscillation-gain dutyfully detoriates. i must have a closer look at this...

revision 4 is up and includes the new filter-mode (and i also re-activated all the other modes again). tuning and resonance of the new 303-alike mode, however, is preliminary

THX to mystran and kunn for deriving this filter

[Music Engineer]

gonna check juce..

kunn gave me some tuning data and i did these approximitations, which are very good, also the gain-compensation for resonance at high cutoffs:

double fx = o * 0.25 * coeff_sqrt05;
// o is omega, 0.25 because of 4x oversampling, coeff_sqrt05 is sqrt(0.5)
a0 = (0.00045522346 + 6.1922189 * fx) / (1.0 + 12.358354 * fx + 4.4156345 * (fx * fx));
k = fx*(fx*(fx*(fx*(fx*(fx+7198.6997)-5837.7917)-476.47308)+614.95611)+213.87126)+16.998792;

double gc = k * 0.058823529411764705882352941176471; // 17 reciprocal
gc = (gc - 1.0) * r + 1.0; // R is 0 to 1.0 ;]
gc = (gc * (1.0 + r));

k = k * r; // K is ready now

<filter>
.. stage4 ... out = y4 * gc; // gc doesn't affect the feedack or anything

now, i did changed the K coefficient a little, to be able to have another knob control the "ground level" for the resonance, while still r=1 equals full-feedback

double rg = <knob_val>; // resonance ground?! ;P~
r = r * (1.0 - rg) + rg;
k = r * k; // K is ready

hey, cool - tuning formulas for the 303 model? exactly what i was just about to look into?

[antto]

so, juce is GPL, and as far as i understand, i can't use it in a "closed-source" application? i must pay for a comercial license blah

my biggest problem about doing GUI stuff with windows, is that i find the damn msdn online documentation very difficult/slow to browse, and i always need to ask a few questions after i read a page there

juce is cross-platform, which is good, but i have no interest in using any other OS than windows mainly (and from time to time Linux, tho, i really don't use it that much at all)
but it would be good to have a "layer" sepparating my own code with the OS-specific stuff (what juce is doing i guess)
maybe it won't be so bad (considering juce's license) for me to try and learn the damn winapi enough write my own "layer" or something, to wrap some window-creation functions, and GDI drawing stuff into classes, which i would be able to change later, without this affecting my other code

not sure, but no matter if i would use this, or some juce-like solution, i will still spend a bunch of time in learning it before i can use it, so maybe i'll have to go on my own with winapi ;]
(and i'll end up with a big pile of messy classes, nothing wrong with that, as long as it works for me, right?)

[Music Engineer]

so, juce is GPL, and as far as i understand, i can't use it in a "closed-source" application? i must pay for a comercial license

correct. however, i think the licensing options are really fair. as long as you are programming for your own fun, there shouldn't be a problem with either releasing under GPL or not releasing at all. if, at some later stage, you get more serious, the license is worth its price. i bought mine ...mmm 2 or 3 years ago or so (after playing around with juce for another 2 years) - although being a considerable investment, and i did never regret it

no matter if i would use this, or some juce-like solution, i will still spend a bunch of time in learning it before i can use it, so maybe i'll have to go on my own with winapi

do you expect that leraning winapi will take less time? i wouldn't. however, it might occasionaly be advantageous to be familiar with winapi as well. your decision

[deraudrl]

my biggest problem about doing GUI stuff with windows, is that i find the damn msdn online documentation very difficult/slow to browse, and i always need to ask a few questions after i read a page there

juce is cross-platform, which is good, but i have no interest in using any other OS than windows mainly (and from time to time Linux, tho, i really don't use it that much at all)
but it would be good to have a "layer" sepparating my own code with the OS-specific stuff (what juce is doing i guess)
maybe it won't be so bad (considering juce's license) for me to try and learn the damn winapi enough write my own "layer" or something, to wrap some window-creation functions, and GDI drawing stuff into classes, which i would be able to change later, without this affecting my other code

not sure, but no matter if i would use this, or some juce-like solution, i will still spend a bunch of time in learning it before i can use it, so maybe i'll have to go on my own with winapi ;]
(and i'll end up with a big pile of messy classes, nothing wrong with that, as long as it works for me, right?)

Speaking as someone who has done a lot of Windows (non-VST) software, I'd avoid WINAPI for this type of stuff unless there was no other option, and in this case there are several.

Let's see: wrapper classes hiding Windows GDI, targeted to VSTi applications, without Juce's GPL baggage...sounds like VSTGUI to me. It seems to get bad-mouthed here more than it really deserves, but for a GUI as simple as this one (and by 'simple', I mean a limited number of different types of controls), there's no real drawback to using it.

[antto]

yeah, juce would work if i only wanted to make myself a VST oscilloscope
but there is a graphic's guy sleeping inside me, and once i finaly get the hang of it (getting comfortable with C++ and GUI functions) i'll be doing lot's of pixel stuff..
so i am thinking a bit more than just a private oscilloscope plugin here ;]

i know, i hate to deal with winapi, juce-like solutions are far better, they keep you away from winapi, and you don't need to worry about anything
i'm sure the price for a license is worth it.. but i currently need shoes without holes on the fingers more than a juce-license

btw, (some time ago) i wrote a big-fat-messy software-3D-renderer (wireframe+shaded with Z-Buffer and everything) using only my own knowladge of 3D rendering, and GDI
but i had a bunch of guys helping me out with the window and the HDC stuff
everything else was simple to me, SetPixelV() and GetPixel() was all i needed, i wrote my own functions for drawing lines, antialiased lines, and gradient-filled triangles.. (plaintext-3D ASCII mesh loader, ZBuffer, mouse-look/walk, cameras)
i did this when i was learning C++ (arrays of pointers, classes, pointers to objects, filestreams, functions) just to see how far i can go, it ended up a big messy project that has no real use, but i learned how pointers work, and i can see a bunch of design mistakes i did, that i try to avoid now ;]
so it was useful to me

what confuses me in winapi are the events, keyboard/mouse, paint, update, and all of these "device context" bullcrap
i had to "invent" my own bitmap format to be able to load it into my own frame buffer (i know i can load a .bmp into a HBITMAP object, but i just get mad with MSDN when i have to go back-and-forward between 5-10 pages to do it on my own)
anyway, i'm currently messing with the 303, but i will look into GUI stuff again sooner or later

in the mean time, any good (and freeware) VST oscilloscope plugin is needed
i couldn't find one in the KVR database last time i checked
i'm using SynthEdit's Scope3 module, SavedAs-VST.. it's OK (good thing is i can scale the time) but there is a problem with it, it tryies to "sync" with positive zero-crossings, and the picture is "jumpy" .. my eyes hurt from that

[deraudrl]

in the mean time, any good (and freeware) VST oscilloscope plugin is needed
i couldn't find one in the KVR database last time i checked
i'm using SynthEdit's Scope3 module, SavedAs-VST.. it's OK (good thing is i can scale the time) but there is a problem with it, it tryies to "sync" with positive zero-crossings, and the picture is "jumpy" .. my eyes hurt from that

The two I know of both suffer from that problem to some extent...then again, so do real hardware scopes when working with unstable signals.

s(M)exoscope (http://www.kvraudio.com/get/971.html) allows you to adjust triggering options, which helps a lot. (Causes an annoying but apparently harmless memory allocation error in vsthost on exit.)

Robin's Signal Analyzer (http://www.kvraudio.com/get/3116.html)

The one from Blue Cat (http://www.bluecataudio.com/Products/Pr ... copeMulti/) isn't free, but if it's as good as their spectrum analyzer, it's definitely worth the $50 they're asking. {EDIT: the limitations of the demo don't appear to be show-stoppers...I'm downloading it now, will report back later.)

[antto]

Robin's Signal Analyzer is great! very fast update rate, both for the scope and the FFT
aah, thanks ;]
only if i could change the colors a little..
anyway, better than what i had before ;]