From the original SynthMaker forum (2004–2014), with its members’ names and dates.
unkargherth ·
Let me know what you think
Instead of asking for this and this other module taht features this and this operation on this andthis signal type, would be anice try to create a kind of math evaluator, alla code module where you could write a sequence of math operations on an undeterminedtype of data ( float preferably, but integer could be nice too). A module with lots of Embbeded math funtions ( trigonometirc,exponential, logarithmic and so on)
As far as i see. shouldn't be so hard to code. The editor is done, the code interpreter is done ( only need to know about some matyh functions). Simply subsititute poly and mono ins and outs for floats and integers
This way the users could develop most of math side itselfs , leaving synthmaker team time to fight with bugs and add new features.
Add your own comments to this, and state the requierments you think usefulñ for the functionality of this module
stefan ·
Uhm. Just add float types to the code module and more functions?
unkargherth ·
Welll, some other optimizations could arise:
.- There's a need this module process poly's?
.- Thre's a need this module process at samplerate rate, once per sample?
For me the diferentiation is more of a csound-like clasification
.- Code module process audio at audio rate
.- Math module process control signals at control rate
( if such diferentiation exists in synthedit, i'm not sure)
This way we don't be forced to obtain ultra fast optimizations. I'm doing something on this way. Taking out the hard math from the main code module into a second one, that don't receive audio signals, only float-type inputs ( although they're declared as poly of course), so i expect it will only be called when this inputs change, not for every sample
Sk ·
There are millions of possible combinations. To be flexible, such a module should allow the user to choose the interconnections, so it is just useless. My 2 cents.
stefan ·
unkargherth wrote: Welll, some other optimizations could arise:
.- There's a need this module process poly's?
.- Thre's a need this module process at samplerate rate, once per sample?
For me the diferentiation is more of a csound-like clasification
.- Code module process audio at audio rate
.- Math module process control signals at control rate
( if such diferentiation exists in synthedit, i'm not sure)
This way we don't be forced to obtain ultra fast optimizations. I'm doing something on this way. Taking out the hard math from the main code module into a second one, that don't receive audio signals, only float-type inputs ( although they're declared as poly of course), so i expect it will only be called when this inputs change, not for every sample
If using float ins/outs on the module, the expressions applying to those would only be calculated when the inputs changed. Not at audio rate. That's what I meant by adding float types to the current code module.
unkargherth ·
Sk wrote: There are millions of possible combinations. To be flexible, such a module should allow the user to choose the interconnections, so it is just useless. My 2 cents.
Surely i didn't explained properly. An example could help
Imagine a code module when you can type this:
floatin x;
floatin y;
floatin z;
floatout res;
float pi; // local variable
pi=3.141592653
res=pow((sin(pi*x),tanh(10*y)/log(z), 4);
( the formula is a nosense, only an example )
You define what inputs and ouputs you want and how to mainpulate them
clear enough now?
jorge ·
unkargherth wrote: clear enough now?
yeah, it's very clear. I had understood it before anyway. I think it's a good idea. A way around it at the moment would be to use the analyser and get it to run just 1 sample, it would be very easy to change the analyser to output the last float value calculated. That way the exact same code used with the analyser could be used for the sound.
Sk ·
Sorry, I'm missing something. The improvement in what you say would be if SM, as of now, hadn't definitions for the functions you say. But I thought that sin, cos, arcsin, tanh, log and so on *were* in SM. Am I wrong on this?
If I got it right, now they must be implemented through Taylor approssimations or similar methods, but with your modules you could simpy tipe sin(x) and you have it. Right? If it is so, then it makes sense. I thought you wanted to create a module with the different functions in it, input and output. *That* was stupid.
unkargherth ·
To Sk:only sin1 , cos1 and tan1 are implemented in the code module by now. Inverse trigonometirc ( arcsin, arccos,..) nor Hyperbolic trihonometric ( tanh, cosh and inverses) not. Also we don't have by now pow,log,ln nor sqrt functions
Some of them, as hyperbolic trigonometrics can be approximated by taylor series For a small range of inputs (see this post). But cannot be done for the others ( specifically, log, ln and pow). Talking to jorge he told me that SQRT is easily implemntable as one assembler call, so we better wait for it
Anyway the most wanted feature is to have float in and float out vars in the Code module (integers will be nice to).
rl ·
unkargherth wrote: Talking to jorge he told me that SQRT is easily implemntable as one assembler call, so we better wait for it
NB: what subset of the IA32/SSE instruction set is supported by the ASM module?
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker