Open303 - open source 303 emulation project - collaborators wanted

[kunn]

kunn: will the one with all the nonlinearities sound different/better or something? haven't tested it

the non-linearities make it sound differerent when driving the filter really hard. u get distortion and cutoff FM.

[antto]

ahum
btw, as far as my experience goes (both your filter, and the older modified-moog-ladder i used before) my impressions are:
overdriving the input (so it clips in the filter already) isn't interesting
interesting is when the filter goes into selfoscillation, but get's "restricted" by the clippers

btw, are the real nonlinearities in the analog filter tanh() shaped? i *think* i read/saw/heard somewhere it was more like hardclipping?

[Music Engineer]

Hi guys,

sorry for being so quiet for a while, but i was actually not much around here at KVR anyway. the reason was that i was working on some neural network code which took much longer than i anticipated ...debugging backpropagation turned out to be a bitch - in that light, it's kinda funny that some people here called me by my old pseudonym. oddly, i'm not even quite sure what to do with this code now. i merely wrote it for ...mmm...fun? intellectual challenge, maybe? currently, i have only some vague ideas how to apply it to audio.

@Muon:
yes, the source of AcidDevil shall be open - i posted it here, but for other parties to actually be able contribute to the code, i think i first need to set up some organized way to do so. i'll look into sourceforge - i already created an account for this project even before posting here, but did not yet upload it there. ...mmm...not yet sure about it, but maybe i'll also include my JUCE based GUI stuff at some stage - which would imply GPL.

btw.: i'm perfectly fine when others work on parallel projects - the discussion here is helpful regardless. specifically antto has posted a lot of valuable research results. surely i'm aware that only a limited amount of information can be gathered from samples alone which is why i'm also very happy when people explain the circuits

O.K. - i have to read through a bunch of pages of forum posts now...

[antto]

neural networks? eek ;]
i read some articles about it (starting off with the one at dspguide) and i'm pretty amazed/interested in such things, and i got really nasty ideas involving neural networks and filters
anyway

i agree, this thread got too big too fast, and it's hard if you try to find some specific post (a "fact" or "data" or something like that) somewhere back..

tho, for a project like this, there should still be a discussion, only that the valuable stuff should be placed on something like a wiki (sepparate from the blah-blah)
if so - i'm in, only that i really can't help with the hosting

as for Dave (from Muon) and any other guy who said that (or spoke like) he knows some *secrets/facts* about the 303 that we haven't yet figured out, let me tell you something (IMO)
i think one of the goals of this thread was to discuss various aspects of the TB-303 synth, and put stuff to the test, you know.. like myth-busters
3ms "attack" - busted
square "flipping every other cycle of the sawtooth.. bullcrap" - busted
resonance being modulated (increased) on accented notes - busted
3 pole filter - wtf?

and so on..
to me, this is what is important, at least, lets find what information is wrong, so that we don't fall in holes
if you got something you really know about the synth, which is important, why not say it? we'll discuss it as usual
if you think we've said something that is wrong, why not tell us

i'm the only one who's talking all the time - yeah, which might be bad, but i think i am the only one "telling" something about the 303 all the time, most of the times i might be wrong, but no one told me i was till i found my mistakes later

so, be useful..

[antto]

i agree..

and also:
(wikipedia, http://en.wikipedia.org/wiki/Software_d ... nt_process )

Waterfall processes
The waterfall model shows a process, where developers are to follow these steps in order:

1) Requirements specification (AKA Verification or Analysis)
2) Design
3) Construction (AKA implementation or coding)
4) Integration
5) Testing and debugging (AKA validation)
6) Installation (AKA deployment)
7) Maintenance

This topic started of in step 3, then went back to step 2, then 1, en then back up..

pretty good example of the differences between "a project" and "this project here"

now, let's not forget that we can't just "simulate" the circuit digitaly (like a SPICE simulation) and derive some big-fat algorithms out of there..

1) <- we are here, most of the times
2) <- can't really design it till step 1 is finished
3) <- you need to get to here, so you can improve the results of step 1

this is what i think is happening, and it looks like itteratively reducing the error (pretty much like what CurveExpert does when it searches for an approximitation to a curve)
is this bad? - no, any other (better) alternative?

rv0: this wasn't directed at you, just you mentioned something that i felt i had to comment

hope the others understand the difference between "a project" and this project here

now, Dave: i think you can't simply make a "model" or something, by which you can emulate an analog synth (what you were interested in)
since, most synths are different, even that most of them use similar tricks, and the same cheap parts
also, in one synth, the important thing might be the modulation, in other - some fat unison, in a third - some wierd sequencer

and i think the "tools" should be detirmined on the run ;]
when you say "a project emulating an analog synth" you probably imagine some guys having at least 1 real synth, dissasembled, and a bunch of wires "hacked" in
this is not the case here
only rv0 has a real TB-303 here, and he's doing whatever he can (and probably more?) to help (and he does, no matter what you think about analyzing samples)
not sure about the other guys, but as for me - i won't have such an amount of money to buy myself a 303, at least not in the near future

and btw, an audio sample can tell A LOT .. if you know how to look at it
but you probably don't believe this

ok, said what i wanted to say ;]

[Music Engineer]

neural networks? eek ;]
i read some articles about it (starting off with the one at dspguide) and i'm pretty amazed/interested in such things, and i got really nasty ideas involving neural networks and filters

really? maybe that would make for another thread then. in the coming days, however, i'll try to get some sourceforge repository for this project here up and running

[antto]

yeah, sadly i haven't yet tested any NN model myself, since it looks like it requires good OO programing skills, which i miss
start a thread, it's good, NN looks to me like the "smartest" thing a computer can do
EOOT (end of off topic)

EDIT: btw, sourceforge: okay, but there must be someone there to "drive the car" you know.. we can all talk around what we think and believe, someone has to decide what is true, and what is false
i don't want this to be me

we already have used different approaches in some places that makes things different
for example, i use linear decay envelopes, and put shapers (curves) over them, you were going for a (more analogish) decaying RC envelopes, which is what the TB-303 has, but then my measurements are hard to be used in that

yet i am still not sure about how this RC decay thing can make something close to the curve i measured (which is a good approximitation)

it's things like this that someone must decide

[Muon Software Ltd]

now, Dave: i think you can't simply make a "model" or something, by which you can emulate an analog synth (what you were interested in)
since, most synths are different, even that most of them use similar tricks, and the same cheap parts
also, in one synth, the important thing might be the modulation, in other - some fat unison, in a third - some wierd sequencer

and i think the "tools" should be detirmined on the run ;]

Although I cannot really understand how such misunderstandings occur (I guess we're going to have to blame language difficulties) but there clearly has been a misunderstanding of huge proportions.

I am interested in a *metholodolgy* and a set of *tools* that can be used to examine an analogue synth - preferably without taking it apart like I did with my 303 - and derive useful information about its structure that can then be emulated.

An example - you said that you had a tool/script that took a spectrogram as input, worked out the X-Y of the brightest pixel and translated that into something you could use to work out the envelope shape. That is the kind of tool and methodology I am talking about.

I have several of these kind of tools - and I'm interested to share them on an open-source basis, but only if contributions make them better. Are you understanding me better yet?

only rv0 has a real TB-303 here, and he's doing whatever he can

No that isn't true - I have one right in front of me.

as for Dave (from Muon) and any other guy who said that (or spoke like) he knows some *secrets/facts* about the 303 that we haven't yet figured out

Now that we know that it is clear that you haven't read or understood a large amount of what I posted, then I'm not going to take offense at yet another misunderstanding.

What I said is that with some simple modifications, you can get access to the raw oscillator output of the 303 and the raw filter input. That in turn gives you very valuable information about the properties of the oscillator and the filter which might not immediately be apparent from samples because of the limitations inherent in the tools that I referred to before.

Thing is, although I can modify a 303, I'm not confident I would want to take apart, say a Juno 60. So it would be better if there was a set of good tools that could be used to derive information about filter envelopes, filter responses, oscillator harmonics etc. *without* having to take the target synth apart. Sitting here on my own though I don't see a way of doing that - and that is why I'm interested in collaborating with other people to solve this particular problem.

Do you understand what I am talking about now? or do you prefer your biased interpretation which puts me in a bad light for no reason?

i think one of the goals of this thread was to discuss various aspects of the TB-303 synth, and put stuff to the test, you know.. like myth-busters
3ms "attack" - busted
square "flipping every other cycle of the sawtooth.. bullcrap" - busted
resonance being modulated (increased) on accented notes - busted
3 pole filter - wtf?

I've never subscribed, or propagated, any of those myths - and you have to remember that Roland themselves referred to the 303 as having an 18db/octave filter because they didn't want to get sued by Moog

i'll look into sourceforge - i already created an account for this project even before posting here, but did not yet upload it there. ...mmm...not yet sure about it, but maybe i'll also include my JUCE based GUI stuff at some stage - which would imply GPL.

Robin - that's good news. I think it will encourage contributions to your code.

[mystran]

i'll look into sourceforge - i already created an account for this project even before posting here, but did not yet upload it there. ...mmm...not yet sure about it, but maybe i'll also include my JUCE based GUI stuff at some stage - which would imply GPL.

Robin - that's good news. I think it will encourage contributions to your code.

It will probably encourage some contributions and discourage others. I personally made a decision some 5 years ago not to touch any GPL code with a ten foot pole, unless (1) it's totally separate from everything else I do (2) it's my own code that I made GPL before I decided on the particular policy (3) I'm not going to distribute any changes anyway.

It should be noted I don't personally mind other similar licenses (even with the exact same rules as per GPL) as long as they are incompatible with GPL.

[Muon Software Ltd]

Before I start I have to say that I have a limited understanding of open-source licenses. However if Robin decides on including his JUCE GUI code, and JUCE is under the GPL, then his code must also be GPL, correct?

I have no problem with the idea of contributing to a GPL project - I intend to keep my code that was written for commercial purposes and anything I do in the open-source world totally seperate. Surely a GPL license is a good thing for a couple of reasons:-

1) Helps to prevent open source code showing up in closed source products without credit - and the GPL has been tested in court.

2) Ensures that any changes that are made to the code are done in the public domain, with source attached.

What is it about the GPL that makes it worthy of the 10-foot pole? am I being naive?

[Caco]

What is it about the GPL that makes it worthy of the 10-foot pole? am I being naive?

A lot of people consider it viral as it infects everything it touches - If you link to a GPL library then you have to make the entire program GPL as well, which makes it tricky to use multiple libraries with different licences within your program.

[mystran]

What is it about the GPL that makes it worthy of the 10-foot pole? am I being naive?

FSF recommends using GPL version X or any later version (as most projects do), which effectively means you are potentially licensing code with terms to be later changed by FSF. So you'd have to trust FSF, which is not a natural person. The people in charge of FSF right now could (probably) be trusted, but you'd also have to trust FSF never ends up in hands of people with opposing ideologies.

There's also the Linux alternative of choosing a specific version of GPL. That sort of solves the above problem, though I'm not quite sure if this effectively makes the license incompatible with code under the X or later clause (since it places an additional restriction on the code). Not being a lawyer, I also choose to avoid this problem.

Finally I prefer much less restrictive licenses for open-source personally. Yes, something like a MIT license is normally taken to be compatible with GPL as well, as it effectively would treat GPL as just another commercial license. The key thing then is that if I place something under a MIT license, then even if someone wants to use it in a GPL project (which they can do) there is still a complete version of the codebase which is not controlled by FSF. If the GPL version advances the code, it those changes can't be applied back, but that would be the case with a commercial license as well: I could live with that, as it doesn't place GPL in any special position controlled by a single organization somewhere (in this case FSF, which I have nothing against specifically).

I don't mean GPL is evil or anything, or that other should agree with the above rationale. It's just how I choose to live (because I admit that I find FSF idea of freedom somewhat different from my own).

Yeah, if you want JUCE GUI it probably means GPL then.

[Muon Software Ltd]

if you want JUCE GUI it probably means GPL then

Not me specifically, but it does kind of emphasise the point about the GPL being viral

[Mike Janney]

I've never subscribed, or propagated, any of those myths - and you have to remember that Roland themselves referred to the 303 as having an 18db/octave filter because they didn't want to get sued by Moog

It *does* indeed have an 18db/octave response, though it is a 4-pole filter.
Actually the filter slope varies between 18 and 24dB depending on the cutoff frequency and is also slightly different from unit to unit.

[Muon Software Ltd]

It *does* indeed have an 18db/octave response, though it is a 4-pole filter. Actually the filter slope varies between 18 and 24dB depending on the cutoff frequency and is also slightly different from unit to unit.

Yup, indeed.