besides the fact it's no fun to connect hundrets of inputs and there is still the problem that SM slows down extrememly, when sizeof(code) > 100 lines, which makes the whole thing rather unusable.
What about an input for Array Data? The example would rather look like:
streamout out;
streamin mem [256];
float i = 0;
loop (256) {
out = out + mem[i] * wadda +yadda;
...
i=i+1;
}
Could be also usable on wave buffer data, graph data, etc.
Oh, and Array output would also be nice (mappable to various Array datatypes)
Shifrin ·
rl wrote: What about an input for Array Data? The example would rather look like:
+1
Yes, definitely need an input for arrays! 😍
Shif.
lalo ·
+1=3 🙂
i'm in too
TheAudiophileDutchman ·
Great idea! 😀
This would also be 'enabling technology' for dynamic memory allocation of arrays being used inside the code component, right? 🙂 😇
sambean ·
Hmmmmm... Array input for code.... 🙂
oddson ·
Sorry if I'm missing the point on this...
Would this mean reading an array at sample rate? That is, would the code reload the array on each run through or just on stage 0?
djaram ·
(Array Input)++
rl ·
oddson wrote: Sorry if I'm missing the point on this...
Would this mean reading an array at sample rate? That is, would the code reload the array on each run through or just on stage 0?
Depending on SM internal structures. If an array is just a location in memory, a read could be done by a single MOV instruction.
In my FR I was thinking in terms of FloatArray (read: green data)
Developers?
oddson ·
But even a static array would be a lot of load if it's read 44,100 times per second. At present all the inputs seem to be reread at stage 1 as well as stage 0.
Sorry if I'm not getting it. My code understanding is a little limited. 😕
malc ·
It's certainly a good idea and it's something we've been considering. I was speaking with Stefan about this in relation to mem buffers just the other day.
Jorge is the code component man here so I'll happily drop him into the frame as the guy that needs to be pestered about this 😈
As I understand it one key performance issue is the fact that the code componect only handles floats. So reading from mem buffers would require a float to int conversion every time you index an array entry. For the static arrays that you currently declare in the code component this has to be done already so I guess it's no worse. However, for mem buffers you'd get better performance using the Read components as they use integers internally to index the mem arrays.
Regarding the reading at sampling rate, rl is right and that's what the Read component does already.
In summary, I'm pretty sure this can be done but there may be an overhead for converting floats to ints for mem buffers.
rl ·
why not support int for simple things like loop counters and array indices in the code component then? (maybe because some additional integer arithmetic has to be supported?)
for the float -> int conversion the code component could provide a f2i() primitive that internally does some optimized conversion (maybe using a single FISTP instruction)
this topic is becoming interesting 😈
lalo ·
rl wrote: why not support int for simple things like loop counters and array indices in the code component then?
jorge told me some time ago that loop counters cannot be provided as a variable...due to some code compilation issue...
lalo
rl ·
should be no problem:
streamout out;
streamin mem [256];
float cnt = 0; // or even better: int cnt = 0;
loop (256) {
out = out + mem[cnt] * wadda +yadda;
...
cnt=cnt+1;
}
this wouldn't break the rules according to fixed loop count. This is already possibe, btw. The new thing would be the Array type connector .
sambean ·
Would it not be possible to have variable loop sizes as long if you kept the variable for the loops size as a mono input?
To optomise the delay I released recently I'm going to have to do just that using the asm..
I'm also with rl with regards to ints/polyints this would be really useful for optimising customised oscs/wav players/waveshapers etc..
Cheers
Sam
rl ·
B u m p ! !
two and half years later and no progress?
kirkagur ·
I saw that there is a mem input in the assembler code....
rl ·
I've seen that too, but it doesn't work (nor is it an official feature).
Any chance for a statement from the SM headquarters?
mark ·
Pleeeeeaaaaaase !!! We need this !!! 😀
TheAudiophileDutchman ·
@Malc: do you remember the experiments we performed on memory access in relation to long samples and compression algorithms? I would love to see this stuff being 'CPU-optimized and exposed to the public' in the next SM-update 😇 🙂
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker