Code thread

Hengy · 6 Jun 2005

this is a bit blue sky, but matrices and optimised matrix operators (ok i'll go back to matlab now 😉 )

unkargherth · 6 Jun 2005

Nu Audio Science wrote: Wants and needs and such 🙂 Stefs away so were losing a big chunk of info but he'll be back

Well, my two cents on what i FEEL be useful in code module

.- Math functions ( exp, log, pow basically) .- A random function outside the stage(0) .- Global array vars and.... user defined functions .- Truncate to smallest int ( or rndint options) . Think jorge is fighting this .- ASM{} directive: a way to code ASM directly in code module. something like

asm { ....non-loop,no-calls sse asm here.... }

...MOre or less in priorityt order IMHO

jorge · 6 Jun 2005

Hengy wrote: this is a bit blue sky, but matrices and optimised matrix operators

very fast SSE matrix operations will be possible when you have arrays exposed through array connectors. You can then use arrays to represent matrices with the first two values meaning number of columns and number of rows with the actual values following.

Shifrin · 6 Jun 2005

unkargherth wrote: .- Math functions ( exp, log, pow basically) .- A random function outside the stage(0)

They'd do me great for now 🙂

Shif.

Nu Audio Science · 7 Jun 2005

Yep i knew Unk would know what was needed 🙂 C'mon Shif you must have some wish's (You Unk and Stef are the code Gurus round here so we need ideas from you three really 🙂 - Although everyone has to admit that Unk and Stef do tidy up a lot of other peoples code Ahem Mine mainly 😉 )

Shifrin · 7 Jun 2005

Nu Audio Science wrote: C'mon Shif you must have some wish's

Well, not too many actually and the other things I'd like are bugfixes 😉

* Nested Loops, i.e. to have a loop within a loop - which is not currently possible.

* The stage(0) construct to work in exported VSTs, at the moment any VST I export with a code component and a stage(0) crashes (should have posted this in the bugs section but I already mentioned I had crashes with stage(0) so that probably covers it).

* User defined functions and global arrays would be cool too like Unk said, and the ability to pass arrays from one code component to another 🙂

Shif.

Tom7777 · 7 Jun 2005

NAS why not just use normal inputs and represent the wavs with floats? im guessing your going to be wanting to do something complex with this maybe though so thats why. Rompler or something?

rl · 7 Jun 2005

- more math functions - user definable functions / subroutines to be used everywhere in the schematic - !!!! FLOAT CODE MODULEs that do only run on input change (not at sample rate) !!!!!!!!!! - a way to access graph data. Example: There is this great FFT Module. It would be nice to mangle some FFT'd data for spectral processing. (Also needs an inverse FFT) - oversampling

Shifrin · 7 Jun 2005

rl wrote: - !!!! FLOAT CODE MODULEs that do only run on input change (not at sample rate) !!!!!!!!!!

Yup, that'd be a time/space (schematic wise) saver for sure 🙂

rl wrote: - a way to access graph data. Example: There is this great FFT Module. It would be nice to mangle some FFT'd data for spectral processing. (Also needs an inverse FFT)

Hadn't thought of that, would be utterly awesome to be able to manipulate FFT'd data.

rl wrote: - oversamping

You can do it for your own oscillators, but not sure about up/down-sampling in the sense of an effect. Might be possible already. Although to have this functionality built in would be neat!

Shif.

Hengy · 7 Jun 2005

I was thinking about user definable functions myself, perhaps implemented by the ability to call code modules from within other code modules or perhaps more like macro statements that just help reduce typing.

The more I thought about them the more i started to get a conceptual problem. The problem i get is as you start expanding the code modules with calls etc you end up in the situation i keep finding myself, which is thinking about how to code the whole synth in a code module and forgetting the rest of synthmaker. You could be in danger of losing the visual coding aspect of synthmaker.

I wonder if some of these ideas are better implemented outside of the code modules, leaving the code modules as very tight dsp modules?

for example wrt to some of the (really interesting) ideas already mentioned for oversampling there could be sub-modules that could be set to run at different sample rates from the main synth, with auto upsampling/downsampling at the interfaces. code modules within these would run at the appropriate rate (this would let me go further with my current messing around with wavelet anaylsis) and for graph data there could be a graph to poly module.

thoughts anyone? does this make any sense?

platinumears · 7 Jun 2005

Hengy wrote: for oversampling there could be sub-modules that could be set to run at different sample rates from the main synth, with auto upsampling/downsampling at the interfaces. code modules within these would run at the appropriate rate (this would let me go further with my current messing around with wavelet anaylsis)

I would love to see this! It might be better if it were implemented at a module level though: that way you wouldn't need to represent upsampled audio signals differently, they would simply be up / down sampled automagically on their way in or out of the module. This would allow an entire plug to be oversampled if needed, or just critical modules within it.

Also, is there currently any way to process doubles? Consider it a request if not!

Dan 🙂

unkargherth · 7 Jun 2005

Hengy wrote: I wonder if some of these ideas are better implemented outside of the code modules, leaving the code modules as very tight dsp modules?

Well, The idea of functions isn'y to code whole synth in code module (it would be a nightmare). What i'm suggesting is to have a a way to define a small func ( maybe a macro) with current code tools. Something simpler, like:

func tanh() { polyin x; polyout o; float x2,x3,x4,x5,x6,x7; ...calculate here..... o=result; }

The most important idea here is to have LOCAL vars. There's no need a REAL function call, coudl be a kind of CUT and PASTE MACRO, provide vars are local This way would be easy to define a more or less standard "user-defined function set", instead of requesting malc and jorge once and again each function individually

platinumears wrote: I would love to see this! It might be better if it were implemented at a module level though: that way you wouldn't need to represent upsampled audio signals differently, they would simply be up / down sampled automagically on their way in or out of the module. This would allow an entire plug to be oversampled if needed, or just critical modules within it.

I remember a topic on this. Suspect that malc and jorge are trying to find a way to do it, but, IMHO it isn't simple, althought5 it will be very nice to have it

platinumears wrote: Also, is there currently any way to process doubles? Consider it a request if not!

Also previously discussed, But , AFAIK, there's no SSE equivalent for doubles, so they would be, at least 4 times slower than floats

Shifrin · 7 Jun 2005

unkargherth wrote: AFAIK, there's no SSE equivalent for doubles, so they would be, at least 4 times slower than floats

That's my understanding of it too.

Shif.

jorge · 7 Jun 2005

unkargherth wrote: Also previously discussed, But , AFAIK, there's no SSE equivalent for doubles, so they would be, at least 4 times slower than floats

Actually there is, but each SSE instruction operates on 2 doubles rather than 4 floats. So it would be 2 times slower rather than 4.

It's not too hard to implement a version working with doubles but I'm not sure when it will become top priority.

Hengy · 7 Jun 2005

platinumears wrote: I would love to see this! It might be better if it were implemented at a module level though: that way you wouldn't need to represent upsampled audio signals differently, they would simply be up / down sampled automagically on their way in or out of the module. This would allow an entire plug to be oversampled if needed, or just critical modules within it.

i agree with you 100%, that's exacty what i meant, my use of the term submodules was misleading, my meaning was a module container that has a sampling rate setting, with exactly as you say auto up/down sampling at the interfaces

Hengy · 7 Jun 2005

unkargherth wrote: Well, The idea of functions isn'y to code whole synth in code module (it would be a nightmare). What i'm suggesting is to have a a way to define a small func ( maybe a macro) with current code tools.

i certainly support the idea of macro like functions, anything that saves typing gets my vote 🙂

platinumears · 8 Jun 2005

jorge wrote: Actually there is, but each SSE instruction operates on 2 doubles rather than 4 floats. So it would be 2 times slower rather than 4.

It's not too hard to implement a version working with doubles but I'm not sure when it will become top priority.

Great! No hurry! 😉 I managed to get a 64-bit version of the RBJ filters coded as an SE module for me for a project I'm working on, and I've come to the conclusion that it sounds rather better than the 32-bit version, especially with extreme settings.. its good to know I will someday be able to do this in SM without needing to bribe module developers! 😀

Dan 🙂