jump tables (-Edit- Eliminating conditional statements :-))

[falemagn]

I've done that, it's very fast, but not very interesting and litmits you to the algorythm you choose when you wrote the program.

Err... ever heard of the work "plugin"? :-P

[bloodline]

falemagn wrote:

I've done that, it's very fast, but not very interesting and litmits you to the algorythm you choose when you wrote the program.

Err... ever heard of the word "plugin"? :-P

You honestly expect me to figure out how to implement a plugin system?!?! :-D

I prefer the virtual DSP idea anyway, as it is platform independant and is not limited to this project ;-)

[Karlos]

@bloodline

You know, function jumpt tables are one way to implement a plug in mechansim ;-)

Unlike switch/case constructs (booo rubbish) a function table can me modified at runtime :-)

[falemagn]

You honestly expect me to figure out how to implement a plugin system?!?!

Uh... you have functions, you have a functiontable, you take the address of the functions and put them in the table...

Amiga-like shared libraries offer plugin functionality for free :-)

I prefer the virtual DSP idea anyway, as it is platform independant and is not limited to this project

You may just as well compile the functions on the fly. Have them written in C/C++, invoke the compiler, load them.

Fast and portable. Yes, you need to ship with or rely on a C compiler, but so what?

The other approach would be to compile your own scripting/opcode language. Unless you want to allow for self-modifying filters (:-o), compiling them will always give better perfomances than interpreting them.

[bloodline]

falemagn wrote:

You honestly expect me to figure out how to implement a plugin system?!?!

Uh... you have functions, you have a functiontable, you take the address of the functions and put them in the table...

Amiga-like shared libraries offer plugin functionality for free :-)

Yeah, I had thought about that. But at the end of the day that is more hassle than I want to be bothered with :-)

I prefer the virtual DSP idea anyway, as it is platform independant and is not limited to this project

You may just as well compile the functions on the fly. Have them written in C/C++, invoke the compiler, load them.

Fast and portable. Yes, you need to ship with or rely on a C compiler, but so what?

The other approach would be to compile your own scripting/opcode language. Unless you want to allow for self-modifying filters (:-o), compiling them will always give better perfomances than interpreting them.

No the DSP won't have (write) access to the memory where the opcode language is stored, so no Self-modifying code. :-)

As mentioned eariler in the thread some kind of JIT would be fun, but that is later project :-)

Also the DSP could have basic functions (standard filters etc...) which would obviously be compiled into the interpretor.

[Karlos]

The binary script interpreter may be slower than a native mechanism, but 1000x more fun to do :-)

[falemagn]

Karlos wrote:
The binary script interpreter may be slower than a native mechanism, but 1000x more fun to do :-)

Well, I kind of think it distracts you from the real code, doesn't it? I mean, Matt should be concentrating on writing the "sound" part of the code, not the interpreter :-)

Anyway, just came across this SMALL language. Quite interesting...

[minatorb]

Well, I kind of think it distracts you from the real code, doesn't it? I mean, Matt should be concentrating on writing the "sound" part of the code, not the interpreter

He's doing this as a hobby so I think this is more of an intellectual excercise than anything else.

Anyway, just came across this SMALL language. Quite interesting...

If you want a small language do it properly :-D
It was even written on an Amiga!

[bloodline]

minatorb wrote:

Well, I kind of think it distracts you from the real code, doesn't it? I mean, Matt should be concentrating on writing the "sound" part of the code, not the interpreter

He's doing this as a hobby so I think this is more of an intellectual excercise than anything else.

That's true. I have several Commercial and opensource software synth packages, that are far more powerful and useful than any program I have the ability or time to make.

So I thought I would try something innovative rather than useful :-)

Anyway, just came across this SMALL language. Quite interesting...

If you want a small language do it properly :-D
It was even written on an Amiga!

SMALL looks cool! :-o

I don't like BF... try writing a virtual DSP in it :-P

[falemagn]

SMALL looks cool!

Indeed it does. And it gets compiled down to bytecode. It's precisely what you need, give it a look :-)