12 Dec
2002
12 Dec
'02
6:27 p.m.
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/
just "make" if you want to test it
Its really hacky insomnia perl code, so dont look at it ;)
It works by defining graphs (.g), that are made up of atoms (C code) and
other graphs. The perl script turns it all into one giant lump of C and
builds it.
Graph files look like eg (pinknoise.g):
noise n(); // declares an instance n
zm1 d();
mix2to1 m();
gain half(0.5f);
n:out -> m:in1; // connect the 'out' port of n to the 'in' port of
m
n:out -> d:in;
d:out -> m:in2;
m:out -> half:in;
half:out -> this:out; // an output from this module to the parent graph
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 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
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.
Its quite cool building up modules from gain and z^-1 units though :)
- Steve
12 Dec
12 Dec
10 p.m.
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)
13 Dec
13 Dec
6:24 a.m.
On Fri, Dec 13, 2002 at 02:50:52AM +0000, Simon Jenkins wrote:
Its just programmer lazyness, the modules are resolved in an order
determined by a hashtable they get stored in.
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.
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
12 Dec
12 Dec
10:28 p.m.
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.
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
13 Dec
13 Dec
6:32 a.m.
On Friday 13 December 2002 03.21, Tim Goetze 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?
[...]
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 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 ---
7:37 a.m.
On Fri, Dec 13, 2002 at 11:27:07 +0100, David Olofson wrote:
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
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.
10:19 a.m.
On Friday 13 December 2002 12.32, Steve Harris wrote:
On Fri, Dec 13, 2002 at 11:27:07 +0100, David Olofson
wrote:
Well, the *dependencies* are in the reverse order, in relation to the
processing... (Not that I know if pd worries about dependencies at
all. :-)
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.
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 ---
6:40 a.m.
On Fri, Dec 13, 2002 at 03:21:21AM +0100, Tim Goetze wrote:
It would be trivial to fix, but I dont see the point, as it stands its not
useful anyway. Its also probably buggy as hell, the perl just handles the
minimum for what I wanted to test.
Its just proof of concept. You /could/ build a system like this if you
wanted to, someone may want to do it for real at some point. If so I'l
gladly lend a hand, but what it needs most is GUI skills and I just dont
have those.
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
(better than either IMHO) isn't commony availble standalone, so perl is
the the fastest devel language I know.
If I was going to do it for real I would reimplement it in C + lex & yacc.
The .g files are just the simplest thing to transform into C, so they
have some odd syntax.
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 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.
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.
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.
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.
It would also be pretty easy to make it produce LADSPA plugins instead of
executables.
- Steve
11:35 a.m.
Steve Harris wrote:
.py is really darn easy to learn and has the benefit of being
readable the day after. :)
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 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
12:08 p.m.
On Friday 13 December 2002 3:28 pm, Tim Goetze wrote:
Steve Harris 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.
If this could compile into LADSPA plugins it would be seriously cool...
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. 
1:02 p.m.
On Fri, Dec 13, 2002 at 04:06:46PM +0000, 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!"
1:46 p.m.
On Fri, Dec 13, 2002 at 08:57:19 -0800, Paul Winkler wrote:
On Fri, Dec 13, 2002 at 04:06:46PM +0000, 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
14 Dec
14 Dec
5:09 p.m.
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 :)
13 Dec
13 Dec
1:41 p.m.
On Fri, Dec 13, 2002 at 04:28:11 +0100, Tim Goetze wrote:
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 ;)
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
.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. :) 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. 
3:02 p.m.
On Fri, 13 Dec 2002, Steve Harris wrote:
On Fri, Dec 13, 2002 at 04:28:11 +0100, Tim Goetze
wrote:
No, one half day. :)
The documentation at www.python.org is wonderful.
--
.py is really darn easy to learn and has the
benefit of being
readable the day after. :)
Yeah... one day.
15 Dec
15 Dec
12:52 p.m.
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)
1:35 p.m.
On Sun, Dec 15, 2002 at 05:43:01PM +0000, Simon Jenkins wrote:
Steve Harris wrote:
It sounds like you'd be better off working form the Sfront SAOL code.
- Steve
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.
2:56 p.m.
Steve Harris wrote:
On Sun, Dec 15, 2002 at 05:43:01PM +0000, Simon Jenkins
wrote:
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)
Steve Harris wrote:
It sounds like you'd be better off working form the Sfront SAOL code.
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.
4:47 p.m.
On Sun, Dec 15, 2002 at 07:47:07PM +0000, Simon Jenkins wrote:
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!"
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 :)
16 Dec
16 Dec
2:43 p.m.
*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 +0000, 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)
6:15 p.m.
On Mon, Dec 16, 2002 at 07:33:39PM +0000, Simon Jenkins wrote:
(BTW I know I was probably misrepresenting Perl when I
called it a
write-only language.
I wasn't defending Perl. :)
I misunderstood the exchange - I thought that you thought
that sfront *was* the quick hack in perl.
I will quit yakkin' now.
--
Paul Winkler
http://www.slinkp.com
"Welcome to Muppet Labs, where the future is made - today!"
8:32 p.m.
On Monday 16 December 2002 20.33, Simon Jenkins wrote:
*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:
*hehe* Well, that's the problem. How the h*ll do one get time to
hack!? Pull the coax from the modem? :-)
//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 -'
--- http://olofson.net --- http://www.reologica.se ---
17 Dec
17 Dec
7:50 a.m.
On Mon, Dec 16, 2002 at 07:33:39 +0000, Simon Jenkins wrote:
(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.)
I dont think you're misrepresenting Perl. That's exactly what it is.
I wouldn't touch the horrible thing but it has strange addictive
effects...
- Steve
13 Dec
13 Dec
12:52 p.m.
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
1:56 p.m.
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
7814
days inactive
7819
days old
linux-audio-dev@lists.linuxaudio.org
24 comments
9 participants
participants (9)
-
David Olofson -
Fernando Pablo Lopez-Lezcano -
Kjetil S. Matheussen -
Maarten de Boer -
Nathaniel Virgo -
Paul Winkler -
Simon Jenkins -
Steve Harris -
Tim Goetze