Saving parts of the schematic as asm code?

stefan · 17 Mar 2005

You can already extract the generated asm code... 🙂 The code component outputs the asm code, so does the poly2mono converter.

Kitchen Sink · 17 Mar 2005

Wow. 😮 How come I haven't noticed that even though I'm in the habit of checking the site every couple of months... A

jorge · 17 Mar 2005

Here is an example that shows you how you can look at the machine code generated by the code component:

It would be easy to export the asm/machine code in other ways, depends exactly what you'd have in mind, I'd need to know more details.

We could also provide some kind of C++ code wrapper so that you could just copy and paste the assembler code inside it, compile/build it, and use it as a normal function call or C++ class.

There are small differences between the code in SM and pure asm because SM works on 4 channels at a time using SSE instructions. When you want to operate on a separate channel using FPU, you have to index that channel, like for example:

fld in[0]; fstp out[0]; fld in[1]; fstp out[1]; etc....

In pure asm you dont index variables that way. It would be easy enough to change that to make it pure asm and compatible with other compilers. Actually, thinking about it, you can already look at the pure asm disassembled code coming out of the PolyToMono component.

Your idea is not bad but I guess we'd only implement it when/if there is someone very interested that can test it for us and provide enough feedback.

Kitchen Sink · 17 Mar 2005

Actually, I meant the code generated from an entire synth. I'd try using it for making some 4k intros, if you know what I mean. Currently we've been using a real simple player, because it needs to fit in a very small space and can't use any library functions, not to even mention C++ object programming. It's just a fun hobby for me and my friends (since 14 years already... are we too old?), so we're not too serious about it.

But anyway, this opens up a whole world of possibilities even now already. I'll look at it and what it can do.

Is there any kind of documentation for the internal language...?

Btw, did you have any use for the incremental graph layout paper I sent you a year ago? 🙂

stefan · 17 Mar 2005

I know what you mean, I've made music and synthesizers for 4k intros as well as 64k intros (you've probably seen them). You can get the code for en entire synth from the poly2mono converter.

Kitchen Sink · 17 Mar 2005

jorge wrote: you can already look at the pure asm disassembled code coming out of the PolyToMono component.

I tried it with the example synth by connecting the outputs of the synth module to a Poly to Mono component, and the output seemed only something like 120 lines long... is that possible? There seems to be a lot of references to variables outside that bit of code, of course, and those things would need to be known at least as symbolic names, to be able to use that code somewhere.

jorge · 17 Mar 2005

Kitchen Sink wrote: I tried it with the example synth by connecting the outputs of the synth module to a Poly to Mono component, and the output seemed only something like 120 lines long... is that possible? There seems to be a lot of references to variables outside that bit of code, of course, and those things would need to be known at least as symbolic names, to be able to use that code somewhere.

There might be some recent asm comands that are not yet supported by the disassembler although it is very easy to fix it. The code references sound process memory which is separate from the machine code area itself but it uses a base pointer + index so it is probably easy to use it generally outside SM just by changing the base pointer. We still need to think a bit about it, maybe a real life example would be a good way to try to make it work.

If you're stuck because you need the disassembler to support all the instructions let me know and I'll fix it. Might be more useful to create a simple example of using SM compiled code outside SM and get it to work.

jorge · 17 Mar 2005

Kitchen Sink wrote: Is there any kind of documentation for the internal language...?

Not yet, I think it will happen soon, meanwhile feel free to ask. It doesnt have many funtions at all but stefan seems to be able to do anything with it. Basically, even with just multiplications and additions you can do everything using taylor expansions etc. but the idea is to make it more user friendly than that. Some of the funtions it supports are: sin1, cos1, tan1, max, min, rndint, hop, >, >=, <, <=, *, +, /, -, %.... I'll probably add more as they're needed, so feel free to request. There are no conditional jumps as the code works on four channels at the same time but there are efficient ways around it.

Kitchen Sink wrote: Btw, did you have any use for the incremental graph layout paper I sent you a year ago? 🙂

I studied it carefully, I decided I was going to implement it, I thought it was really good. When Malc joined we decided we'd create two systems, bendy links and the automatic routing. Malc implemented the bendy links first and because it is working well, the automatic routing stopped being a priority. Would you still like to have it as an option to the bendy links? do you think it is better?

galaa · 17 Mar 2005

jorge wrote: Some of the funtions it supports are: sin1, cos1, tan1, max, min, rndint, hop, >, >=, <, <=, *, +, /, -, %.... I'll probably add more as they're needed, so feel free to request.

Would it be possible to implement some kind of random number generator

Kitchen Sink · 17 Mar 2005

jorge wrote: There are no conditional jumps as the code works on four channels at the same time but there are efficient ways around it.

If it only uses SIMD instructions, I guess it won't be possible to have a 64 bit internal signal path too easily...? That's one of the things that can raise the overall level of DSP sound quality a bit, as well as internal oversampling and high-quality resampling and band-limiting.

Malc implemented the bendy links first and because it is working well, the automatic routing stopped being a priority. Would you still like to have it as an option to the bendy links? do you think it is better?

No, I think the bendy links work surprisingly well, even though they have to be manually adjusted. Actually I'm very impressed! There are some algorithms that could help to generate bendy links automatically, like the one described in this paper: http://www.gradetools.com/karlisf/curved.html The paper says it was quite slow, though...

stefan · 17 Mar 2005

Kitchen Sink wrote: jorge wrote: There are no conditional jumps as the code works on four channels at the same time but there are efficient ways around it.

If it only uses SIMD instructions, I guess it won't be possible to have a 64 bit internal signal path too easily...? That's one of the things that can raise the overall level of DSP sound quality a bit, as well as internal oversampling and high-quality resampling and band-limiting.

64bit can very rarely make a difference. In some kinds of filters maybe, but usually it's nothing to be concerned with. Internal oversampling and band-limiting is ofcourse doable and I don't see how one could make SM _not_ allowing these kind of things. I use oversampling and band-limiting in my filters and in my distortion.

Kitchen Sink · 17 Mar 2005

I think "all 64 bit" is a trend of the future, and eventually all DAW programs and plugins will use it. Maybe not next year, but in a few years. Now that we have nice 64 bit processors, suddenly it becomes a perfectly viable option to use 64 bit everywhere, without getting any performance hit. You know, not all plugin makers optimize for SIMD, so for them, they just change floats to doubles, and that's it. And if history repeats itself, when the 64 bit revolution is far enough, new processors will start performing very badly with 32 bit data, just like what happened with 16 vs. 32 bit. Would you use a 16 bit data type today?

IMO, having more bits can have an effect in DSP, because 32 bit floats only have 24 (or 25) bits of integer precision, and it's easy to imagine that accumulating rounding errors can become audible and decrease clarity. I think there's a reason why Voxengo is using 64 bit processing... I can't say I've done extensive double-blind testing, though.

stefan · 17 Mar 2005

In a few years, no doubt we will have simd instructions working on 64bit data 🙂

jorge · 17 Mar 2005

Kitchen Sink wrote: If it only uses SIMD instructions, I guess it won't be possible to have a 64 bit internal signal path too easily...?

It's not only SIMD instructions, x86 instructions too, but to take advantage of SIMD instructions SM processes 4 channels at the same time.

I can easily create the start of another code component for 64 bit internal signal path, I think you're aware it would run 4 times slower, do you think that's still useful?

I have planned a general modular compiler that lets you define the language itself with low-level components, that could shift a lot of the work from us to the users.

We also have the beginning of a code component to be used for the other types of data like Midi, Floats, Ints, Strings etc. It still needs more work but it might start to become useful very soon.

jorge · 17 Mar 2005

Kitchen Sink wrote: Now that we have nice 64 bit processors, suddenly it becomes a perfectly viable option to use 64 bit everywhere, without getting any performance hit.

I think you get a performance hit, SSE variables take 128 bits. No matter how fast the 64 bit processor is, it will be faster using SSE as the bottleneck is normally with data flowing.

Kitchen Sink wrote: You know, not all plugin makers optimize for SIMD, so for them, they just change floats to doubles, and that's it.

but the ones that optimize for SIMD have all the extra power to do extra stuff.

Kitchen Sink wrote: And if history repeats itself, when the 64 bit revolution is far enough, new processors will start performing very badly with 32 bit data, just like what happened with 16 vs. 32 bit. Would you use a 16 bit data type today?

yeah, but it wouldnt be a problem with 128 bit SSE variables on a 64 bit processor eventhough the SSE variable represents 4 32bit floats.

Kitchen Sink wrote: I think there's a reason why Voxengo is using 64 bit processing...

I agree, but could the reason be marketing?

jorge · 17 Mar 2005

galaa wrote: Would it be possible to implement some kind of random number generator

I was expecting stefan would post saying "yeah, you can do it already, here is how you do it: some code" 🙂

Arent random generators based on some boolean expression? Maybe it can be done already but I didnt try. If there are some boolean operators missing, I'll be happy to implement them. I think at the moment there's only "&", I guess or "|" and xor "^" might be needed too. I'll have a look at musicdsp.org, maybe it would work similar to generating white noise.

stefan · 17 Mar 2005

I will do one shortly. Without the use of sin1() 🙂

Kitchen Sink · 17 Mar 2005

Many people have reported that Voxengo's PristineSpace sounds better than SIR with the same impulse files... but as I said, I haven't done any double-blind tests myself.

What comes to the 32 vs. 64 thing, I meant, if someone is using 32 bit SISD code on a 32 bit system (which is of course not so advanced and fast as SIMD), the quality gain of using an all 64 bit signal path has to be quite big to justify the lower performance. But when the platform is 64 bit, the SISD guys can just go for it, because it won't cost them anything. And I believe, when that happens, it will raise the overall sound quality - maybe just a tiny bit, but still.

But I'm sure we'll all enjoy the joys of SynthMaker. It's kind of the perfect combination - it allows us to do all kinds of sound design experiments efficiently. Getting the benefits of SSE in a graphical synth/effect building program, and even being able to write bits of code in there too, without needing to code the boring 99% around that 1% of interesting code, it's just superb. You guys are doing some awesome work. If I was 10 years younger and didn't have a full-time job and a family to feed, SynthMaker is something I'd like to be doing! 🙂

stefan · 17 Mar 2005

It will cost them double the memory usage / bandwidth. That is not neglictable.

Difference between PristineSpace and SIR might also be due to the FFT or any other algorithm they are using.

Shifrin · 17 Mar 2005

jorge wrote: We also have the beginning of a code component to be used for the other types of data like Midi, Floats, Ints, Strings etc. It still needs more work but it might start to become useful very soon.

Ooooooooooooooh, I was thinking of asking for something like this - and you're already building it 😉 Great!

stefancrs wrote: I will do one shortly. Without the use of sin1()

Hmmmm, a Mersenne Twister implementation perhaps 😉

Shif.

jorge · 18 Mar 2005

Kitchen Sink wrote: If I was 10 years younger and didn't have a full-time job and a family to feed, SynthMaker is something I'd like to be doing! 🙂

If you're that old, maybe you could retire soon, feed your family with the pension and have a nice retirement working on SM 🙂