Re: [linux-audio-dev] Blockless processing
*hehe* I offer to shut up and code unless somebody pokes me with a sharp stick or something and the next thing that happens is: On Sun, Dec 15, 2002 at 07:47:07PM +, Simon Jenkins wrote: It sounds like you'd be better off working form the Sfront SAOL code. Well, I'm working from scratch at the moment cos your code was written in a write-only language that I currently choose not to understand :) and Paul Winkler wrote: You're confusing things... No I'm not. Steve's quick hack was written in Perl. I know what it was written in. Its a quick hack of a C fragment pasting idea which I contributed to a XAP sub-sub-sub-sub-thread about on-the-fly code generation, so I /have/ been paying attention. There was some discussion of sfront mixed into the same bit of thread (this was during the initial XAP frenzy when the list effectively became a very busy, very lagged IRC channel for a couple of days) but this was a distinct, though related, idea. (BTW I know I was probably misrepresenting Perl when I called it a write-only language. Thats why I added the smiley and made it clear that I don't use it.) Sfront is entirely in C. The fact that sfront is in C is totally irrelevant. The fact that it /generates/ C makes it a close relative of the sort of thing I was talking about (and the work you have done with it for outputting jack clients makes it an even closer relative). But it doesn't make it *into* the thing I was talking about. Anyway, I /was/ talking about it, but now I'm coding it. Simon Jenkins (Bristol, UK)
Re: [linux-audio-dev] Blockless processing
Steve Harris wrote: Damn... dont encourage me. I'm gonna end up implemnting this thing for real if I'm not careful and I allready have a dozen other things that are more important. I'm currently working on my own implementation of this. It'll be a little bit more than proof of concept code, but still a lot less than useable release code. I'll post it up somewhere when its done. Meanwhile I'd better shut up about the whole thing (unless somebody pokes me with a sharp stick or something). Simon Jenkins (Bristol, UK)
Re: [linux-audio-dev] Blockless processing
On Sun, Dec 15, 2002 at 05:43:01PM +, Simon Jenkins wrote: Steve Harris wrote: Damn... dont encourage me. I'm gonna end up implemnting this thing for real if I'm not careful and I allready have a dozen other things that are more important. I'm currently working on my own implementation of this. It'll be a little bit more than proof of concept code, but still a lot less than useable release code. It sounds like you'd be better off working form the Sfront SAOL code. - Steve
Re: [linux-audio-dev] Blockless processing
Steve Harris wrote: On Sun, Dec 15, 2002 at 05:43:01PM +, Simon Jenkins wrote: Steve Harris wrote: Damn... dont encourage me. I'm gonna end up implemnting this thing for real if I'm not careful and I allready have a dozen other things that are more important. I'm currently working on my own implementation of this. It'll be a little bit more than proof of concept code, but still a lot less than useable release code. It sounds like you'd be better off working form the Sfront SAOL code. Well, I'm working from scratch at the moment cos your code was written in a write-only language that I currently choose not to understand :) Besides, I've got some ideas of my own about what direction this sort of approach could be taken in and I feel like investigating them. Simon Jenkins (Bristol, UK)
Re: [linux-audio-dev] Blockless processing
On Sun, Dec 15, 2002 at 07:47:07PM +, Simon Jenkins wrote: It sounds like you'd be better off working form the Sfront SAOL code. Well, I'm working from scratch at the moment cos your code was written in a write-only language that I currently choose not to understand :) You're confusing things... Steve's quick hack was written in Perl. Sfront is entirely in C. Sfront is not a proof of concept, it's been mature for some time now. -- Paul Winkler http://www.slinkp.com Welcome to Muppet Labs, where the future is made - today!
Re: [linux-audio-dev] Blockless processing
What does your thingie do that sfront doesn't do? sfront compiles SAOL / SASL text files (describing a processing synthesis network) down to C which compiles nicely with GCC. SAOL is still block based AFAIK. This allows you to do some really neat tricks with feedback, knowing that the latency is only one sample. In principle you can run any system with a block size of 1, but the performance will really suck. Maybe SAOL would be ok, anyone tried it? the basic idea is not new either... IIRC, Common Music does much the same thing starting from a lisp dialect. Yes, but its lisp :) The package is Common Lisp Music (CLM), does not use blocks (ie: block size = 1), and compiles the sample generation loop of instruments into C from a subset of Common Lisp (instruments are written in Common Lisp). The other parts of the instrument run in compiled lisp. It is quite fast. It is originally based in Common Lisp but there are now two other implementations of the same primitives (unit generators) in both Scheme and C. The scheme port runs on guile and is getting quite close to the Common Lisp / C based CLM in speed (factor of 2 or 3 as I recall). All written by Bill Schottstaed. -- Fernando
Re: [linux-audio-dev] Blockless processing
On Fri, Dec 13, 2002 at 02:50:52AM +, Simon Jenkins wrote: I went as far as defining a biquad filter in the graph format (http://plugin.org.uk/blockless/blockless/modules/biquad.g), but it dosen't quite work because the execution order is more or less random. I haven't looked closely yet but do you mean that the atoms are being executed in some compiler-determined order that doesn't reflect the flow of data through the graph? Its just programmer lazyness, the modules are resolved in an order determined by a hashtable they get stored in. Someone suggested here that single sample latencies, eg in feedback loops, shouldn't cause noticeable problems. (There's got to be one somewhere in a feedback loop anyway). The combined effect of whole load of atoms executing in the wrong order might be a different matter though. Yes, especially in a biquad. value that hasn't been evaluated yet. (OTOH the Modular is a synth not an FPGA and I was well across the line which divides use from abuse before I even noticed that I wasn't in control of the evaluation order). You can control it, its goverened by the order you place the modules in the patch. I managed to build an AD converter that way, but it was damn hard work. The optimisations I'm really hoping to see are for the compiler to strip out dead code when an output isn't connected, and to propogate a constant 0 through the graph when an input isn't connected. Well that happens, the constant 0.0 gets propagated, because I manually set it in the source :) Thinking again about what the Nord Modular does: You can make and break connections between existing modules as much as you like with neither a glitch nor a change in (what it claims to be its) CPU usage. As soon as you add a new module, though, all the existing modules reset themselves and everything starts again with the new module, suggesting that the existing modules have all lost their contexts. This is *really* annoying if you're trying to develop a patch or sequence that evolves very slowly. Yes, It might be possible to replicate this by use of exteme binary mangling, but its not somewhere I want to go. I just did this to see what would happen, if someone were going to take a more serious stab at it they would have to take account of these issues. - Steve
Re: [linux-audio-dev] Blockless processing
On Friday 13 December 2002 03.21, Tim Goetze wrote: [...] I went as far as defining a biquad filter in the graph format (http://plugin.org.uk/blockless/blockless/modules/biquad.g), but it dosen't quite work because the execution order is more or less random. definitely sounds broken, yes. that garbled execution order should be fixed. Sort by dependencies... But is there any obvious way of dealing with feedback loops, or do you explicitly have to specify where you want the delay? Maybe there should just be a way of hinting delay sensitive connections for when you actually have problems? [...] i think the biquad is so common it's ok to have a .c fragment for the operator instead of coding it in your .g language. a generic iir generator? you can do it with some more .pl i guess. Makes sense - but I think it would be nice to be able to deal with these kind of problems when you need to, so you can do filter prototyping and stuff without going back to C. Prototype first, then maybe hack an optimized .c fragment. //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! . | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `--- http://olofson.net/audiality -' .- M A I A -. |The Multimedia Application Integration Architecture| ` http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---
Re: [linux-audio-dev] Blockless processing
On Fri, Dec 13, 2002 at 11:27:07 +0100, David Olofson wrote: Sort by dependencies... But is there any obvious way of dealing with feedback loops, or do you explicitly have to specify where you want the delay? Maybe there should just be a way of hinting delay sensitive connections for when you actually have problems? Yes, I would maybe do what pd does and execute the modules in layout order. Though I think pd goes right to left and bottom to top, which seems backwards. Maybe I've remebered it wrong. If you know that is happening you can layout the graph so it will execute correctly. Alternativly just order them by placement sequence (though users find that confusing apparently ;) or sort by dependencies and pick somewhere at random for the delay. i think the biquad is so common it's ok to have a .c fragment for the operator instead of coding it in your .g language. a generic iir generator? you can do it with some more .pl i guess. Makes sense - but I think it would be nice to be able to deal with these kind of problems when you need to, so you can do filter prototyping and stuff without going back to C. Prototype first, then maybe hack an optimized .c fragment. Yes. Also its quite interesting to be able to delve into filters and see the internal structure. It would be good for teaching if nothing else. This appears to be fast enough that that is practical. - Steve
Re: [linux-audio-dev] Blockless processing
On Friday 13 December 2002 12.32, Steve Harris wrote: On Fri, Dec 13, 2002 at 11:27:07 +0100, David Olofson wrote: Sort by dependencies... But is there any obvious way of dealing with feedback loops, or do you explicitly have to specify where you want the delay? Maybe there should just be a way of hinting delay sensitive connections for when you actually have problems? Yes, I would maybe do what pd does and execute the modules in layout order. Though I think pd goes right to left and bottom to top, which seems backwards. Maybe I've remebered it wrong. Well, the *dependencies* are in the reverse order, in relation to the processing... (Not that I know if pd worries about dependencies at all. :-) If you know that is happening you can layout the graph so it will execute correctly. Alternativly just order them by placement sequence (though users find that confusing apparently ;) or sort by dependencies and pick somewhere at random for the delay. And if you can do the latter, you could pick the specified connecton instead of some random place. //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! . | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `--- http://olofson.net/audiality -' .- M A I A -. |The Multimedia Application Integration Architecture| ` http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---
Re: [linux-audio-dev] Blockless processing
Steve Harris wrote: it's a nice little hack. the .g files don't look that messy to me, whatever hacks may be hiding in your .pl -- which is always a mess to my eyes. Yep, perl is horrible. Unfortunatly I've not learned python and ecmascript .py is really darn easy to learn and has the benefit of being readable the day after. :) If I was going to do it for real I would reimplement it in C + lex yacc. yep, probably the best thing to do. The .g files are just the simplest thing to transform into C, so they have some odd syntax. they're fairly easy to read though. Yeah, absolutly, its just the most complex basic that came to mind, I wanted to check if it could handle loads of modules far down the graph and still produce a decent binary. hard to concede the proof is complete with the garbled biquad. :) You can define subgraphs, but not in the same file. It wouldn't be too hard, but what it would really need is a graphical editor. sure, a gui will be really helpful for complex modules. nonetheless, i think the net description should come in a text-only format. tim
Re: [linux-audio-dev] Blockless processing
On Friday 13 December 2002 3:28 pm, Tim Goetze wrote: Steve Harris wrote: You can define subgraphs, but not in the same file. It wouldn't be too hard, but what it would really need is a graphical editor. sure, a gui will be really helpful for complex modules. nonetheless, i think the net description should come in a text-only format. I don't think a gui is necessary - just a little syntactic sugar would do. After all, people have been using csound for years and it's semantically not too different from this. If this could compile into LADSPA plugins it would be seriously cool...
Re: [linux-audio-dev] Blockless processing
I couldn't resist it so I hacked up a quick script to try the blockless, dynamicly compiled processing we were discussing the other day. Hi, I missed that discussion (do you have a pointer?) but it all seems very much related to the example i posted some while ago: http://www.eca.cx/lad/2002/07/0409.html http://www.eca.cx/lad/2002/07/0410.html with the difference that in my case the same source can be used to either generate efficient code or be compiled and execute at runtime. Maarten
Re: [linux-audio-dev] Blockless processing
On Fri, Dec 13, 2002 at 04:06:46PM +, Nathaniel Virgo wrote: I don't think a gui is necessary - just a little syntactic sugar would do. After all, people have been using csound for years and it's semantically not too different from this. Which reminds me to ask what I've been wondering all along about this discussion... What does your thingie do that sfront doesn't do? sfront compiles SAOL / SASL text files (describing a processing synthesis network) down to C which compiles nicely with GCC. the basic idea is not new either... IIRC, Common Music does much the same thing starting from a lisp dialect. -- Paul Winkler http://www.slinkp.com Welcome to Muppet Labs, where the future is made - today!
Re: [linux-audio-dev] Blockless processing
On Fri, Dec 13, 2002 at 04:28:11 +0100, Tim Goetze wrote: .py is really darn easy to learn and has the benefit of being readable the day after. :) Yeah... one day. Yeah, absolutly, its just the most complex basic that came to mind, I wanted to check if it could handle loads of modules far down the graph and still produce a decent binary. hard to concede the proof is complete with the garbled biquad. :) Well, all the right operations happen, jsut not in the right order. I know how to fix it, so thats nearly as good as actually fixing it ;) You can define subgraphs, but not in the same file. It wouldn't be too hard, but what it would really need is a graphical editor. sure, a gui will be really helpful for complex modules. nonetheless, i think the net description should come in a text-only format. Sure, the .g files should be human readable and editable. It wouldn't be proper UNIX software otherwise. Damn... dont encourage me. I'm gonna end up implemnting this thing for real if I'm not careful and I allready have a dozen other things that are more important. - Steve
Re: [linux-audio-dev] Blockless processing
On Fri, Dec 13, 2002 at 08:57:19 -0800, Paul Winkler wrote: On Fri, Dec 13, 2002 at 04:06:46PM +, Nathaniel Virgo wrote: I don't think a gui is necessary - just a little syntactic sugar would do. After all, people have been using csound for years and it's semantically not too different from this. csound is much higher level, I guess once all the building blocks are defined it would be more practical to build things in text only, but making complex filters is hard work. You really dont want to build an FFT that way either ;) Which reminds me to ask what I've been wondering all along about this discussion... What does your thingie do that sfront doesn't do? sfront compiles SAOL / SASL text files (describing a processing synthesis network) down to C which compiles nicely with GCC. SAOL is still block based AFAIK. This allows you to do some really neat tricks with feedback, knowing that the latency is only one sample. In principle you can run any system with a block size of 1, but the performance will really suck. Maybe SAOL would be ok, anyone tried it? the basic idea is not new either... IIRC, Common Music does much the same thing starting from a lisp dialect. Yes, but its lisp :) - Steve
Re: [linux-audio-dev] Blockless processing
On Fri, Dec 13, 2002 at 05:47:07 +0100, Maarten de Boer wrote: I missed that discussion (do you have a pointer?) but it all seems very much related to the example i posted some while ago: I can't find the discussion, but it came out of the XAP discussions (not that that helps much!). Yeah, its similar. My implementation is based on the idea of SyncModular (though I've no idea how that works internally), processing units are built out of layered graphs. It would be possible to execute it without compiling, but it would be damn slow so I didn't bother. - Steve
Re: [linux-audio-dev] Blockless processing
On Fri, 13 Dec 2002, Steve Harris wrote: On Fri, Dec 13, 2002 at 04:28:11 +0100, Tim Goetze wrote: .py is really darn easy to learn and has the benefit of being readable the day after. :) Yeah... one day. No, one half day. :) The documentation at www.python.org is wonderful. --
Re: [linux-audio-dev] Blockless processing
Steve Harris [EMAIL PROTECTED] writes: SAOL is still block based AFAIK. See: http://www.cs.berkeley.edu/~lazzaro/sa/pubs/pdf/wemp01.pdf Sfront does no block-based optimizations. And for many purposes, sfront is fast enough to do the job. It may very well be that sfront could go even faster with blocking, although the analysis is quite subtle -- in a machine with a large cache, and a moderate-sized SAOL program, you're running your code and your data in the cache most of the time. Remember, blocking doesn't save you any operations, it only improves memory access and overhead costs. If those costs are minimal for a given decoder implementation, there is not as much to gain. - John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro -
Re: [linux-audio-dev] Blockless processing
On Fri, Dec 13, 2002 at 12:25:13 -0800, John Lazzaro wrote: Steve Harris [EMAIL PROTECTED] writes: SAOL is still block based AFAIK. See: http://www.cs.berkeley.edu/~lazzaro/sa/pubs/pdf/wemp01.pdf Sfront does no block-based optimizations. And for many purposes, sfront is fast enough to do the job. OK, I didn't realise that SFront was blockless, well there you go then, thats the answer, use SFront :) - Steve
Re: [linux-audio-dev] Blockless processing
John Lazzaro wrote: Steve Harris [EMAIL PROTECTED] writes: SAOL is still block based AFAIK. See: http://www.cs.berkeley.edu/~lazzaro/sa/pubs/pdf/wemp01.pdf Sfront does no block-based optimizations. And for many purposes, sfront is fast enough to do the job. It may very well be that sfront could go even faster with blocking, although the analysis is quite subtle -- in a machine with a large cache, and a moderate-sized SAOL program, you're running your code and your data in the cache most of the time. I totally agree that there's no intrinsic performance difference between blockless and block-based processing other than what sits better in the cache, and that block-based processing might very well go faster because of this, although it might not. But the plugin scheme we've been discussing under the title of blockless processing raises a few more issues. By doing just-in-time compilation of a whole bunch of connected plugins, which may have been written separately but are now to be connected together into a graph by the host application, you get the following opportunities: + Code optimisation across plugin boundaries (especially powerful if there are unconnected inputs and outputs, or constant control values). + Compile-time parameterisation of plugins (ok, you can do that with any plugin but compile time is actually instantiation time in this scheme so it becomes something the host can specify). + One-sample latency between connected plugins (the original reason this whole thing got discussed IIRC). The compiled result might well be partially or fully block processed - subject to the host tolerating that, and internal feedback loops being processed sample-by-sample - but the compiler would be able to base its optimisation decisions on how the *entire* graph to be processed fitted into the *actual* available cache. Simon Jenkins (Bristol, UK)
Re: [linux-audio-dev] Blockless processing
Steve Harris wrote: I couldn't resist it so I hacked up a quick script to try the blockless, dynamicly compiled processing we were discussing the other day. http://plugin.org.uk/blockless/ Nice! I've only had a very quick look so far, but just knowing it exists has improved my day by quite a bit. I went as far as defining a biquad filter in the graph format (http://plugin.org.uk/blockless/blockless/modules/biquad.g), but it dosen't quite work because the execution order is more or less random. I haven't looked closely yet but do you mean that the atoms are being executed in some compiler-determined order that doesn't reflect the flow of data through the graph? Someone suggested here that single sample latencies, eg in feedback loops, shouldn't cause noticeable problems. (There's got to be one somewhere in a feedback loop anyway). The combined effect of whole load of atoms executing in the wrong order might be a different matter though. Anyway I know this sort of thing can cause problems occasionally because I've suffered them: If you try to do anything too tricky with the logic modules in the Nord Modular you can end up latching a logic value that hasn't been evaluated yet. (OTOH the Modular is a synth not an FPGA and I was well across the line which divides use from abuse before I even noticed that I wasn't in control of the evaluation order). I used the biquad in a simple toplevel graph (http://plugin.org.uk/blockless/blockless/graphs/test4.g), it takes about 50 cycles per sample on PIII (interestingly its compiles to slightly worse code in gcc3.2), the source my script produces is very tangled and funtion-y, but gcc manages to untagle it and inline it all, eg. http://plugin.org.uk/blockless/blockless/intem/test4.c The optimisations I'm really hoping to see are for the compiler to strip out dead code when an output isn't connected, and to propogate a constant 0 through the graph when an input isn't connected. This would need a recompile every time a connection is made (which is already the case in your implementation anyway) rather than just when an atom is added or removed though. Thinking again about what the Nord Modular does: You can make and break connections between existing modules as much as you like with neither a glitch nor a change in (what it claims to be its) CPU usage. As soon as you add a new module, though, all the existing modules reset themselves and everything starts again with the new module, suggesting that the existing modules have all lost their contexts. This is *really* annoying if you're trying to develop a patch or sequence that evolves very slowly. Simon Jenkins (Bristol, UK)
Re: [linux-audio-dev] Blockless processing
Steve Harris wrote: http://plugin.org.uk/blockless/ it's a nice little hack. the .g files don't look that messy to me, whatever hacks may be hiding in your .pl -- which is always a mess to my eyes. I went as far as defining a biquad filter in the graph format (http://plugin.org.uk/blockless/blockless/modules/biquad.g), but it dosen't quite work because the execution order is more or less random. definitely sounds broken, yes. that garbled execution order should be fixed. I used the biquad in a simple toplevel graph (http://plugin.org.uk/blockless/blockless/graphs/test4.g), it takes about 50 cycles per sample on PIII (interestingly its compiles to slightly worse it's an ok cycle count for integer noise and a biquad i think, isn't it? but the sound it produces is useless. i think the biquad is so common it's ok to have a .c fragment for the operator instead of coding it in your .g language. a generic iir generator? you can do it with some more .pl i guess. Its too much work to create a reasonably complex synth or anything in this as theres no UI and keeping all the links straight in your head is painful, so I dont know how well it scales up. if you can define sub-graphs (maybe in the same file), with a little focus you should be able to create more complex networks, too. i think this method could prove handy coding polyphonic soft synths, which is where usual plug-your-graph-together-from-plugins systems invariably add some processing overhead. tim
