Includes for the Assembler primitive

aliasant · 6 Mar 2011

I talked to "an admin" about a similar thing a couple of weeks back. I want to have Float Array OR Mem in but he wasnt thrilled. The problem being that Arrays are trigger based and dont blend well with code. He also said the Mem is the same more or less.

The solution in my case, building my arp/seq, was to have one input for each index of the array and since I only have 64 ( might double it to 128) steps that was doable. I just made extractions to get all the indexes to its own output and then send those in to the code. This actully gave me alot more control over the array values since I can treat them in stream instead.

My guess is that this wont work for you because you need a lot bigger arrays?

Keep nagging Outsim. Maybe they cave in some day.

Array/Mem (or something that does the same or same'ish ) input would be the dream 🙂

So here it is.

+1

Oh. He also mentioned the mysterious mem in that we have in the assembly. Something about that being a left over from Jorges brainstorming / idea testing. Maybe he tried but failed 🙁

TomC · 6 Mar 2011

aliasant wrote: I talked to "an admin" about a similar thing a couple of weeks back. I want to have Float Array OR Mem in but he wasnt thrilled. The problem being that Arrays are trigger based and dont blend well with code.

But this is something completely different, there's NO array visible in the Assembler primitive, so triggers aren't an issue.

I just want to be able to split a huge mess of code into separate small sections of code.

So, the changes for outsim would be:

- read available text from StringArray input - process this text as if it was already inside the Assembler primitive - don't display this text. Only the the text inside the Assembler primitive itself should be visible.

The first 2 points are trivial, the last one needs some work. Should be doable in a couple of hours.

Tom

aliasant · 6 Mar 2011

Still sounds the same as what I wanted. A float Array input that I can call from inside the code. Nothing visible from the array isnide the code.

infuzion · 6 Mar 2011

Arrays tend to be standard for most programming languages...

rl · 6 Mar 2011

I'd appreciate, if we could define some sort of 'subroutines' and "call" them (better include as in C's inline calling) from within either the code module or the ASM module

(...and a pointer to an array or memory buffer - a.k.a. memin - too)

infuzion · 7 Mar 2011

rl wrote: I'd appreciate, if we could define some sort of 'subroutines' and "call" them (better include as in C's inline calling) from within either the code module or the ASM module

We kind of have this already; loop(), or just have linked Codes you can copy & paste. I think the ASM commands for JumpZ are there also?...

In the big picture, though I'd like a more flexable Code & I truly think it a good idea, I'd think having 64bit VST, 64bit/SSE3+ audio, & OSX support alot more important than better Code.

TomC · 7 Mar 2011

infuzion wrote: rl wrote: In the big picture, though I'd like a more flexable Code & I truly think it a good idea, I'd think having 64bit VST, 64bit/SSE3+ audio, & OSX support alot more important than better Code.

I fully agree, but before I posted my request above I carefully thought about the amount of work necessary for outsim. My proposal can be done in a day or so, so the chances that it'll gonna happen are MUCH higher. Your proposals most probably need a complete rework of SynthMaker.

I need a solution NOW, or FFT/iFFT for streams will never happen. At least not by yours truly.

Tom

trogluddite · 7 Mar 2011

rl wrote: (...and a pointer to an array or memory buffer - a.k.a. memin - too)

Yeah, that's a biggie for me at the moment - I'm really craving a way to get big numbers of parameters or sample data into a code/asm array. As aliasant has pointed out, one input per array point is far, far too cumbersome. I don't really get the 'Arrays are trigger driven' objection - an array/mem is just some numbers arranged in a particular fashion in a block of memory, and I fail to see how that is very much different to connecting a green float to a stream input. We may need to take care about execution order to make sure that our data is in place WHEN we expect it to be - but WHERE only requires 3 parameters; the datum memory address, array length, and size of each entry. My guess is that it's actually the 'size of each entry' that is really the problem - current code/asm arrays always carry 128bit 4channel sse entries whereas mem primitives are either 32 or 64 bits per entry (mono/stereo).

infuzion · 7 Mar 2011

TomC wrote: I need a solution NOW, or FFT/iFFT for streams will never happen.

I do not understand why you can not use the current streamin &/or stage(0) system?

trogluddite · 7 Mar 2011

If the problem has to do with feeding in a lot of parameter data (from array or mem), then the main difficulty is that the mem and array read prim's can only access one chunk of data per sample. This renders stage(0) redundant as it only runs for one sample. I've had a little success reading in one value at a time from a stream, but it involves some awkwardness getting the stage timing right, and you have to program custom loops using ASM if the array length is arbitrary.

If the problem is with the sheer size of the code required, I would recommend using an external code editor like notepad++(freeware). By defining custom syntax rules, you can still get full syntax colouring (including checking for variable name spelling, yippee!) - and you get a MUCH faster interface with full search/replace, multiple windows for cut/paste etc.etc. I'd be happy to lend a hand writing a syntax file - I already have one for ASM that I can dig out, and SM Code has so few functions that it shouldn't be hard to define one for that too.

Not at my SM machine at the mo' - but I can post examples later if these options might be of any use.

TomC · 7 Mar 2011

infuzion wrote: TomC wrote: I need a solution NOW, or FFT/iFFT for streams will never happen.

I do not understand why you can not use the current streamin &/or stage(0) system?

Most, if not all, FFT algorithms work on an array of samples either recursive or iterative. If you use a bin size of let's say 8192 samples you have to fill your array sample by sample, process them when it's filled (while a second array is filled at the same time), and output it sample by sample while your process your second array. Then you switch the arrays.

That's not rocket since, but a whole bunch of code. All in one single Assembler primitive. That's not easy to maintain. And even less easy to debug. I can only work a couple of hours each weekend on this, and it gets harder and harder to find where I left just a week ago.

I've already written the input and output routines to build the arrays and output the processed data. The processing itself will be a mess...

Tom

TomC · 7 Mar 2011

trogluddite wrote: I've had a little success reading in one value at a time from a stream...

That's what I do.

trogluddite wrote: If the problem is with the sheer size of the code required, I would recommend using an external code editor like notepad++(freeware). By defining custom syntax rules, you can still get full syntax colouring (including checking for variable name spelling, yippee!) - and you get a MUCH faster interface with full search/replace, multiple windows for cut/paste etc.etc. I'd be happy to lend a hand writing a syntax file - I already have one for ASM that I can dig out, and SM Code has so few functions that it shouldn't be hard to define one for that too.

I already use Notepad++ and have ASM syntax highlighting, but a dedicated SM SSE syntax file would be swell

Still a tedious work, though...

Tom

Edit: Found it, you've already posted it here

trogluddite · 8 Mar 2011

He he, think I'm getting to the age where the things I learn are being overtaken by the things I forget! 😉

TheAudiophileDutchman · 31 Mar 2011

BUMP: we need a MEMIN anytime soon, please Devs! 😇