| Author |
Message |
dewdrop_world
Joined: Aug 28, 2006
Posts: 858
Location: Guangzhou, China
Audio files: 4
|
 Posted: Sun Feb 10, 2008 8:44 pm Post subject:
SuperCollider Q&A
Subject description: Inspired by good questions from ChucKists |
  |
|
Over on the ChucK board, I started a discussion with some questions about ChucK (pretty interesting, touching on some theory). Along the way, some good questions about SuperCollider came up, and I thought it would be better to treat those questions on the SuperCollider board.
So first, I want to look at the question about how timing is handled in SuperCollider. More than one person in the ChucK discussion found this perplexing, and since it's fundamental to any music programming, I think it's the most important question.
At the same time, there was a suggestion on the sc mailing list that we really needed an introductory tutorial on scheduling and sequencing. So I wrote it, thinking to kill the two birds with one stone. (That's why it took so long to get to it. It's actually a lot of material to cover, and to present it step by step takes some care.)
You can read the tutorials in the sourceforge svn repository --
Scheduling Events
Sequencing with Routines and Tasks
Sequencing with Patterns
Please do follow up with questions if anything is unclear. That might point out a place where the documentation could be improved.
Some other great questions were raised in the other thread -- I don't have time tonight to get to them, but I have a list and I'll go through them one at a time.
James
PS The code font (9pt Monaco) may look bad on Windows - I had to format them to conform with standard formatting for the rest of the docs, which was written with Mac in mind. Copy and paste to another program if needed.
_________________
ddw online: http://www.dewdrop-world.net
sc3 online: http://supercollider.sourceforge.net |
|
|
Back to top
|
|
 |
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Mon Feb 11, 2008 6:04 am Post subject:
|
|
|
This looks really good!
Thanks a lot for taking the time to do this. Both the formatting and the content look very readable to me.
_________________
Kassen |
|
|
Back to top
|
|
|
dewdrop_world
Joined: Aug 28, 2006
Posts: 858
Location: Guangzhou, China
Audio files: 4
|
| Posted: Mon Feb 11, 2008 8:12 pm Post subject:
|
|
|
Some of the questions from the original thread:
| Kassen wrote: | | I don't know... I think others had the same experience I had with ChucK except with SC. At times when I look at the code-replacement and some of the great Ugens I envy those people though I don't like block-processing at all and I never understood why separating the "language"and "server" would be a good idea. If I understand correctly what those do I think I'd always want them as close to each other as I could get them. |
Yes and no... integrating the language with audio rendering is probably easier to approach as a new user (which might account, in part, for your observation that it took less time to get up to speed in ChucK compared to SuperCollider). But the separation has some advantages that might not be obvious at first:
- Significant, dramatic simplification of networked music applications. Powerbooks Unplugged, for instance, do things that are straightforward, even easy, in SuperCollider but which would be quite difficult in ChucK (because of the need to instantiate UGens in a remote ChucK VM). It's very easy for a SuperCollider client on one machine to send messages to a server on a different machine.
- Control of synthesis from another language. Offhand, I can think of scsynth clients for Java, Scheme, Python and I think I've even heard of Squeak and Haskell clients. But the only way to run audio in ChucK is using the ChucK language.
| Kassen wrote: | Oh, one thing I don't entirely like is the way ChucK's method of being object oriented works. Here I tend to think very differently from how ChucK works and I tend to want things that are more typical of Prolog, I tend to want do things to all objects in the whole VM or file, sort them and base rules on their type and property... For example open the cut-off on every LPF that takes a wave buffer as a input unless this wave buffer is past half it's buffer, then mark this LPF with some property.
Still, does SC have the ability to do stuff like what I mentioned? For example, could you take a certain scope that was already defined and have SC put references to every object, regardless of type within that scope in a array automatically? (maybe excepting that array itself....). |
Not at the virtual machine level -- object behavior is modeled after smalltalk -- but sure there's a way to implement some kind of global scope for certain objects.
My performance/composition library (named chucklib for my appropriation of the => operator  ) saves higher level objects into global repositories, where you can do some filtering. If you wanted to stop all the processes belonging to one section of a larger piece, but leave others playing, you could do
BP.allOfType(\thisSectionName).stop;
That would be really hard for UGens because the client side objects are used just for synthdef building, and don't track server instances that are actually rendering.
| Kassen wrote: | you do get the data-code thing, right? Say I have a string named foo, formatted to be legal SC syntax this would be legal?
do(10, foo );
And "foo" would still be editable as a string? |
foo = "{ |i| i.postln }";
do(10, foo.interpret);
| Kassen wrote: | | Ok, but doesn't that [argument] syntax cause issues? For example, say I have a SinOsc and I don't know it's current pitch (for example because that's randomly set some time ago) and now I want to change it's volume without affecting it's pitch? I was/am under the impression that I need to supply a argument for pitch if I want to affect the volume? |
Well, there are two things here. First, with keyword addressing of arguments, you can simply omit arguments that you're not interested in.
| Code: | SynthDef(\sinamp, { |amp = 1|
Out.ar(0, SinOsc.ar(mul: amp));
}) |
... is perfectly legal, but boring since it's always 440Hz.
Second, the kind of argument change that you're talking about will come from the client as an OSC message. In the message, you include only the arguments that have to change. There is no need to touch every synthdef control every time.
| Code: | SynthDef(\sine, { |freq = 440, amp = 1|
Out.ar(0, SinOsc.ar(freq, mul: amp));
}).send(s);
a = Synth(\sine);
a.set(\amp, 0.2); // change amp, leave freq alone |
That's all for tonight... followup questions most welcome!
James
_________________
ddw online: http://www.dewdrop-world.net
sc3 online: http://supercollider.sourceforge.net |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Mon Feb 11, 2008 10:21 pm Post subject:
|
|
|
| dewdrop_world wrote: |
Yes and no... integrating the language with audio rendering is probably easier to approach as a new user (which might account, in part, for your observation that it took less time to get up to speed in ChucK compared to SuperCollider).
|
I'm not completely sure either approach is inherently harder or easier. Where would you place Csound from that perspective, for example? To illustrate by example; Just last night I had a good talk with a friend of mine who explained she would control a analogue modular from Cubase while I said I'd always want a sequencer integrated with the modular itself for this. I believe we both thought the other was making things needlessly complicated :¬).
| Quote: | - Significant, dramatic simplification of networked music applications. Powerbooks Unplugged, for instance, do things that are straightforward, even easy, in SuperCollider but which would be quite difficult in ChucK (because of the need to instantiate UGens in a remote ChucK VM). It's very easy for a SuperCollider client on one machine to send messages to a server on a different machine.
|
I've seen Powerbooks Unplugged live :¬)
I never tried this myself but the ChucK docs assure me I can send commands to VM's running on remote hosts if I know the IP and port. This should include the ability to instantiate Ugens, start code that uses them or.... well, basically I would be able to do anything. In that sense you could say the ChucK VM could also be seen as a "server". It could also be seen as a epic security risk as this will include the ability to ask ChucK to ask the OS to delete half the HD or home directory without asking for confirmation, but that's networking for you.
http://chuck.cs.princeton.edu/doc/program/vm.html
under "hostname"
| Quote: | - Control of synthesis from another language. Offhand, I can think of scsynth clients for Java, Scheme, Python and I think I've even heard of Squeak and Haskell clients. But the only way to run audio in ChucK is using the ChucK language.
|
Yes, that's indeed a real difference. So, if one of these clients talks to the server it mainly gives instructions about the creation of Ugens, their settings and interconnections? What's still not clear to me is how SC deals with situations where DSP is needed beyond the usage of Ugens. I don't see what the language is and where the server starts.
Also, as ChucK can send OSC, do I understand correctly that one could write a library of classes for ChucK and so use ChucK as a SC client?
| Quote: |
Not at the virtual machine level -- object behavior is modeled after smalltalk -- but sure there's a way to implement some kind of global scope for certain objects.
My performance/composition library (named chucklib for my appropriation of the => operator ) saves higher level objects into global repositories, where you can do some filtering. If you wanted to stop all the processes belonging to one section of a larger piece, but leave others playing, you could do
BP.allOfType(\thisSectionName).stop;
|
Nice!
| Quote: |
That would be really hard for UGens because the client side objects are used just for synthdef building, and don't track server instances that are actually rendering.
|
Hmmmm, doesn't that construction make audio analysis very hard?
Do regular functions run on the client or the server side? If we want to use SC's superior facilities to re-compile running code, how do we recompile a running synth-def if we lack this tracking? These may be stupid questions but all the docs I saw kept stressing there is a language and a server and these are different.... but they didn't really tell me where this line is or how it works.
| Quote: |
foo = "{ |i| i.postln }";
do(10, foo.interpret);
|
Nice! And this can include defining and instantiating synth-defs? That would allow for some very interesting re-synthesis techniques....
| Quote: |
Well, there are two things here. First, with keyword addressing of arguments, you can simply omit arguments that you're not interested in.
| Code: | SynthDef(\sinamp, { |amp = 1|
Out.ar(0, SinOsc.ar(mul: amp));
}) |
... is perfectly legal, but boring since it's always 440Hz.
Second, the kind of argument change that you're talking about will come from the client as an OSC message. In the message, you include only the arguments that have to change. There is no need to touch every synthdef control every time.
| Code: | SynthDef(\sine, { |freq = 440, amp = 1|
Out.ar(0, SinOsc.ar(freq, mul: amp));
}).send(s);
a = Synth(\sine);
a.set(\amp, 0.2); // change amp, leave freq alone |
That's all for tonight... followup questions most welcome!
James |
This is great stuff. Especially in this last section above I feel your explanations here are a lot more clear then the official docs I saw or mr. Cottle's book. Compared to this those look like obfuscated SC to me.... I mean; I can figure out that 440 refers to a frequency but if there are values like "1" or "0" which could refer to amplitude or phase or modulation index or for all I know some sort of interpolation of tables, it would really be much better if the official tutorials would mention what number goes where before firing off such a train, at least the first few times if we are talking about introductory material. Maybe this was intentional, to encourage people to try changing the numbers but it comes across as less then accessible to me.
I suspect that the ChucK "examples" dir and how accessible it is contributed a large chunk to my learning process, even if you may well be right above. From that perspective I think the current push towards more and better examples in the SC scene is a very good idea.
_________________
Kassen |
|
|
Back to top
|
|
|
dewdrop_world
Joined: Aug 28, 2006
Posts: 858
Location: Guangzhou, China
Audio files: 4
|
| Posted: Tue Feb 19, 2008 8:06 pm Post subject:
|
|
|
More great questions  I promise I'll get back to this. It's been hectic with the final release of the 3.2 stable version coming very soon (should be available for download tomorrow at sourceforge).
I'll be back...
James
_________________
ddw online: http://www.dewdrop-world.net
sc3 online: http://supercollider.sourceforge.net |
|
|
Back to top
|
|
|
dewdrop_world
Joined: Aug 28, 2006
Posts: 858
Location: Guangzhou, China
Audio files: 4
|
| Posted: Wed Feb 20, 2008 8:23 pm Post subject:
|
|
|
I feel like procrastinating...
| Quote: | | Anything that compiles in ChucK shouldn't be able to crash the VM, I don't think you can (try to) make that guarantee like that with weak typing but I'm not sure? |
By "crash," do you mean that the whole application segfaults, or just that the VM throws an error and execution halts? The former is quite bad and doesn't happen in SuperCollider, unless there's a bug in a primitive. The latter seems like graceful error handling to me.
An error in one thread, or in code submitted live to the interpreter, stops only that thread. Other threads continue to run normally. Also, SuperCollider has exception handling, not quite as strict or formalized as in Java but you can still catch an error and decide whether it should cause a failure or not.
| Quote: | | I would be cewl if someone could make a list of the pros and cons of both languages (espessialy about the way they handle time, how they syncronise threads, how they handle midi, ...). |
Tough question! I don't know ChucK well enough to compare them. I'll be glad to answer any questions about SuperCollider, though.
| Quote: | | Yeah, I see where you are coming from. I can see how you don't feel the need for sample accurate sequencing but in ChucK there need not be a difference between how you sequence and how you synthesise. Typically the synthesis is done by Ugens but sometimes those don't quite cover all you need. So; sequencing becomes sample accurate because synthesis needs to be. |
My feeling -- for my uses, just my personal opinion -- is that this makes it harder for me to imagine how to work with sequencing at a really high level of abstraction. But if I spent more time with ChucK, I'm sure I would come up with useful abstractions fairly soon.
| Quote: | | Custom control rates may be somewhat boring when they concern -say- the modulation of a filter's cutoff but they become exciting where the control-rate is some musical amount of time. The controll-rate of a sequencer may be a quarter-note, the control rate of a granular synth may be based on a frequency... |
SuperCollider handles this through triggered UGens, "demand rate" UGens (which move ahead to the next value only when they receive a trigger), or by sending control value changes from the client with precise timing.
Okay, back to coding...
James
_________________
ddw online: http://www.dewdrop-world.net
sc3 online: http://supercollider.sourceforge.net |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Thu Feb 21, 2008 12:52 pm Post subject:
|
|
|
| dewdrop_world wrote: |
By "crash," do you mean that the whole application segfaults, or just that the VM throws an error and execution halts? The former is quite bad and doesn't happen in SuperCollider, unless there's a bug in a primitive. The latter seems like graceful error handling to me.
|
The latter, but speciffically ChucK should only abort execution for the "shred" where the error occurred. This works quite well most of the time, it even goes as far as detecting a shred has likely gotten stuck and offering to kick it out, preserving all the rest of your VM.
Still, there are some bugs left that can kill the whole VM. It's getting harder to do that though, in the past I might find one of those every two weeks or so but now it's cause for genuine surprise.
| Quote: | An error in one thread, or in code submitted live to the interpreter, stops only that thread. Other threads continue to run normally. Also, SuperCollider has exception handling, not quite as strict or formalized as in Java but you can still catch an error and decide whether it should cause a failure or not.
|
Cool! We are going to get something like that as well. Since exceptions are traditionally "thrown" it makes perfect sense to "ChucK" them as well :¬)
Sometimes I wonder what will happen to ChucK-culture if it would ever become completely stable :¬)
| Quote: | | Quote: | | I would be cewl if someone could make a list of the pros and cons of both languages (espessialy about the way they handle time, how they syncronise threads, how they handle midi, ...). |
Tough question! I don't know ChucK well enough to compare them. I'll be glad to answer any questions about SuperCollider, though.
|
We could create a team to build a chart of this? Not now, but some time....
| Quote: |
My feeling -- for my uses, just my personal opinion -- is that this makes it harder for me to imagine how to work with sequencing at a really high level of abstraction. But if I spent more time with ChucK, I'm sure I would come up with useful abstractions fairly soon. |
I do feel that "levels of abstraction" are largely a matter of perception though. I don't imagine that would differ too much between the two.
| Quote: |
SuperCollider handles this through triggered UGens, "demand rate" UGens (which move ahead to the next value only when they receive a trigger), or by sending control value changes from the client with precise timing.
|
That makes a lot of sense. Like many of the topics we've seen so far this is quite equivalent yet the question remains how the different approaches might influence "thinking styles" as per your original question. This is really very interesting, but we may need somebody who speaks both at a relatively advanced level to comment on that.
| Quote: |
Okay, back to coding...
|
Are you working on the current SC updates?
_________________
Kassen |
|
|
Back to top
|
|
|
dewdrop_world
Joined: Aug 28, 2006
Posts: 858
Location: Guangzhou, China
Audio files: 4
|
| Posted: Sun Feb 24, 2008 5:26 pm Post subject:
|
|
|
| Kassen wrote: | | I never tried this myself but the ChucK docs assure me I can send commands to VM's running on remote hosts if I know the IP and port. This should include the ability to instantiate Ugens, start code that uses them or.... well, basically I would be able to do anything. In that sense you could say the ChucK VM could also be seen as a "server". It could also be seen as a epic security risk as this will include the ability to ask ChucK to ask the OS to delete half the HD or home directory without asking for confirmation, but that's networking for you. |
Quite interesting. Yes, it would be a security risk, but you could probably search the code string for instructions that would call the OS and disallow unsavory commands.
Nothing in SuperCollider stops you from opening up the same kind of security hole.
| Code: | | o = OSCpathResponder(nil, ['/interpret'], { |time, responder, msg| msg[1].asString.debug("command").interpret.debug("result") }).add; |
Then, from another machine (or another copy of SuperCollider running on the same machine):
| Code: | n = NetAddr("ip.address.of-first.machine", 57120);
n.sendMsg('/interpret', "'hello world'.postln"); |
| Quote: | | What's still not clear to me is how SC deals with situations where DSP is needed beyond the usage of Ugens. I don't see what the language is and where the server starts. |
We may have to take that on a case by case basis. Some of the UGens provide fairly low-level processing, like standard first order and second order filter sections. If you know your digital filter theory (not my strong point by a long shot), you can go a long way with those and the math UGens.
Conditional evaluation of UGens is admittedly kludgey with the division between client and server. "Do xyz on the server when such and such signal crosses a certain frequency or amplitude threshold" most often requires round-trip OSC between server and client -- the server sends a trigger message to the client, and the client responds by triggering the new action on the server. James McCartney would be the first to admit that this isn't ideal (and in fact this was much easier in SuperCollider 2).
So, unsurprisingly, the choice of tool depends on the application. If you need to trigger activities with sample accuracy based on audio analysis, ChucK would be better since the network communication required in SuperCollider makes it impossible to be sample accurate in that case. SuperCollider is optimized for making a lot of copies of UGen graphs -- by "a lot" I mean thousands, even millions (of course, not all of them would be concurrent, though overlapping within CPU limits works perfectly) -- where this would seem to be more difficult in ChucK, especially without garbage collection.
| Quote: | | Also, as ChucK can send OSC, do I understand correctly that one could write a library of classes for ChucK and so use ChucK as a SC client? |
Yep.
| Quote: | Hmmmm, doesn't that construction make audio analysis very hard?
Do regular functions run on the client or the server side? If we want to use SC's superior facilities to re-compile running code, how do we recompile a running synth-def if we lack this tracking? These may be stupid questions but all the docs I saw kept stressing there is a language and a server and these are different.... but they didn't really tell me where this line is or how it works. |
Functions run only on the client. The server is actually relatively dumb. It stores synthdefs. It can instantiate Synth nodes based on a saved synthdef and evaluate the UGen graph. It can update control data in response to OSC and use audio or other data in buffers. That's about it. The idea of reconfiguring a running Synth node is not part of the server design. You can have alternate branches and choose which one to use at runtime with Select or SelectX, but adding new branches on the fly within a synthdef is just not the way it works.
Now, what you can do instead is break up the synthesis into multiple, simpler synthdefs that share signals on audio or control buses. Then you can change the synthesis by removing one node and replacing it with a different node that reads and writes signals in the same way but processes the signal differently.
I'd say it's a common mistake that new users of SC make -- to try to cram everything into massive, do-all synthdefs. That reduces the number of nodes you have to create and manage, but it severely limits flexibility and can be really inefficient to boot. Say you write a whiz-bang synthdef that includes its own reverb ugens. Now you play a 5-note chord with it -- placing five independent and identical reverbs on the server where one would do just as well and take only 20% of the CPU.
It's up to your code in the client to track active Synth nodes. SuperCollider doesn't impose a high level data structure for this -- if it did, it would be making the bold assumption that everybody's needs would be about the same. It does provide some tools to help, like NodeWatcher (which I use routinely), but you decide how to use the information from those tools.
| Quote: | | Quote: |
foo = "{ |i| i.postln }";
do(10, foo.interpret);
|
Nice! And this can include defining and instantiating synth-defs? That would allow for some very interesting re-synthesis techniques.... |
At the first SuperCollider symposium in Birmingham, Dan Stowell showed off some genetic algorithms he had developed to converge on a synthdef that would try to reproduce an arbitrary (finite-length) signal.
More later -- oh yeah... I have been involved in getting 3.2 ready for release (probably TOO involved). But with that release out, I'm retreating from dev work and getting started on a new piece (which is what this is all about, after all!).
James
_________________
ddw online: http://www.dewdrop-world.net
sc3 online: http://supercollider.sourceforge.net |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Mon Feb 25, 2008 12:28 pm Post subject:
|
|
|
| dewdrop_world wrote: |
Quite interesting. Yes, it would be a security risk, but you could probably search the code string for instructions that would call the OS and disallow unsavory commands.
|
I have been leaning towards (by default) ignoring networked commands that don't originate from local host as a solution, not sure how easy that would be. Searching code strings is probably too much, if we consider the size of the various Unix shells, their syntax and exactly what "unsavoury" means. For example; clearly deleting files is "bad" yet evidently deleting files you just wrote is fine.... except you shouldn't write audio data over system files, not even as root, etc, etc, etc.
| Quote: | Nothing in SuperCollider stops you from opening up the same kind of security hole.
|
Well, power-tools can maim.... It's a delicate balance between power and risk, I was just talking with Ge about this very matter.
| Quote: |
We may have to take that on a case by case basis. Some of the UGens provide fairly low-level processing, like standard first order and second order filter sections. If you know your digital filter theory (not my strong point by a long shot), you can go a long way with those and the math UGens.
Conditional evaluation of UGens is admittedly kludgey with the division between client and server. "Do xyz on the server when such and such signal crosses a certain frequency or amplitude threshold" most often requires round-trip OSC between server and client -- the server sends a trigger message to the client, and the client responds by triggering the new action on the server. James McCartney would be the first to admit that this isn't ideal (and in fact this was much easier in SuperCollider 2).
|
Yes, I see. That "round trip" does add power but for timing you are at the mercy of the OS.
Here ChucK may be more general at the expense as -on average- taking more CPU and more custom structures. That's a concrete difference then which could indeed affect "thinking styles".
| Quote: | | So, unsurprisingly, the choice of tool depends on the application. If you need to trigger activities with sample accuracy based on audio analysis, ChucK would be better since the network communication required in SuperCollider makes it impossible to be sample accurate in that case. SuperCollider is optimized for making a lot of copies of UGen graphs -- by "a lot" I mean thousands, even millions (of course, not all of them would be concurrent, though overlapping within CPU limits works perfectly) -- where this would seem to be more difficult in ChucK, especially without garbage collection. |
Yes, agreed.
| Quote: |
Functions run only on the client. The server is actually relatively dumb. It stores synthdefs. It can instantiate Synth nodes based on a saved synthdef and evaluate the UGen graph. It can update control data in response to OSC and use audio or other data in buffers. That's about it. The idea of reconfiguring a running Synth node is not part of the server design. You can have alternate branches and choose which one to use at runtime with Select or SelectX, but adding new branches on the fly within a synthdef is just not the way it works.
Now, what you can do instead is break up the synthesis into multiple, simpler synthdefs that share signals on audio or control buses. Then you can change the synthesis by removing one node and replacing it with a different node that reads and writes signals in the same way but processes the signal differently.
I'd say it's a common mistake that new users of SC make -- to try to cram everything into massive, do-all synthdefs. That reduces the number of nodes you have to create and manage, but it severely limits flexibility and can be really inefficient to boot. Say you write a whiz-bang synthdef that includes its own reverb ugens. Now you play a 5-note chord with it -- placing five independent and identical reverbs on the server where one would do just as well and take only 20% of the CPU.
It's up to your code in the client to track active Synth nodes. SuperCollider doesn't impose a high level data structure for this -- if it did, it would be making the bold assumption that everybody's needs would be about the same. It does provide some tools to help, like NodeWatcher (which I use routinely), but you decide how to use the information from those tools. |
Yes, this makes a lot of sense to me, it's certainly coherent within it's own paradigm.
| Quote: |
At the first SuperCollider symposium in Birmingham, Dan Stowell showed off some genetic algorithms he had developed to converge on a synthdef that would try to reproduce an arbitrary (finite-length) signal. |
This is very interesting indeed.
| Quote: | More later -- oh yeah... I have been involved in getting 3.2 ready for release (probably TOO involved). But with that release out, I'm retreating from dev work and getting started on a new piece (which is what this is all about, after all!).
|
Well.... you have to warm a serious recorder (as in flute) with your hands, wax wooden instruments, re-string stringed instruments.... You can see it as a distraction but I think it also deepens your relationship to the instrument. I think that here Open Source instruments offer analogies to acoustical ones that commercial software ones lack.
:¬)
Thanks a lot, I think that at the moment you answered most of my questions.... but I'm sure the future will bring more. I very much appreciate you taking the time for this.
_________________
Kassen |
|
|
Back to top
|
|
|
Ludvig
Joined: Jul 25, 2005
Posts: 26
Location: Stockholm - Sweden
|
| Posted: Wed May 14, 2008 9:42 am Post subject:
|
|
|
Thank you dewdrop_world!
Those tutorials were really well written. They cleared up a lot of things for me. |
|
|
Back to top
|
|
|
ixemul
Joined: Jul 29, 2008
Posts: 4
Location: Waterloo,ON
|
| Posted: Tue Nov 25, 2008 8:47 pm Post subject:
Patterns vs. Pattern Filters |
|
|
Hello,
First, a big thank you to dewdrop_world for putting these tutorials, they helped me to finally get over the hump and start making some noise in SC.
I have a question about the pattern examples though, specifically around Pbind - I tried to replace the Pseqs in the Pbind examples with more complex pattern statements and eventually got around to trying to stick Pstutter and other filters in only to find that using pattern filters in a Pbind doesn't (seem to) work - no error, but no sound from the speakers either.
I know enough about OOP to surmise that there's something going on here that really wants a Pattern and not a PatternFilter, but I'm a bit lost as to how to proceed. Is there some way to wrap a Pstutter, for example, to make it look like happy pattern for Pbind?
Thanks,
Chris |
|
|
Back to top
|
|
|
dewdrop_world
Joined: Aug 28, 2006
Posts: 858
Location: Guangzhou, China
Audio files: 4
|
| Posted: Fri Nov 28, 2008 6:35 pm Post subject:
|
|
|
Pstutter works fine in Pbind:
| Code: | (
p = Pbind(
\degree, Pstutter(Pwhite(3, 8, inf), Pwhite(0, 10, inf)),
\dur, Pstutter(Pwhite(3, 8, inf), Prand(#[0.125, 0.25, 0.5], inf)),
\legato, 0.4,
\amp, 0.02
).play;
)
p.stop; |
hjh
_________________
ddw online: http://www.dewdrop-world.net
sc3 online: http://supercollider.sourceforge.net |
|
|
Back to top
|
|
|
ixemul
Joined: Jul 29, 2008
Posts: 4
Location: Waterloo,ON
|
| Posted: Sat Nov 29, 2008 9:54 am Post subject:
Pstutter |
|
|
Thanks, I had some bad logic in the code I was fooling around with; your example helped to clarify.
Got it working now! |
|
|
Back to top
|
|
|
Acoustic Interloper
Joined: Jul 07, 2007
Posts: 2065
Location: Berks County, PA
Audio files: 89
|
Posted: Sat Dec 04, 2010 11:49 am Post subject:
Re: SuperCollider Q&A
Subject description: Inspired by good questions from ChucKists |
|
|
Looks like these are gone. Any way to get at them? Thanks!
_________________
When the stream is deep
my wild little dog frolics,
when shallow, she drinks. |
|
|
Back to top
|
|
|
Acoustic Interloper
Joined: Jul 07, 2007
Posts: 2065
Location: Berks County, PA
Audio files: 89
|
| Posted: Sat Dec 04, 2010 2:05 pm Post subject:
|
|
|
I might as while ask a question in the meantime 
My current ChucK project that I need to finish over Christmas, has to do with capturing an audio recording and then, based on OSC messages passed from a Java GUI to ChucK as triggered by my GUI control clicks during speech, segments and rearranges subsequences of the recording, playing the recording back in the rearranged sequences. The ChucK patch doesn't actually modify the Lisa recording, it just starts and stops playback at various places. Kassen helped Ryan my grad student learn to use Lisa last spring for this.
The original goal was rearrangement of spoken word passages based on grammar. The speaker does the "speech recognition," clicking buttons at phrase boundaries, which tell Chuck where to place boundaries for later rearrangement.
I found 2 things of interest: 1. Low amplitude transitions correlate with phrase boundaries, allowing me to avoid hitting the buttons by treating long pauses as phrase boundaries (this is good -- I tend to click too early or occasionally too late), and 2. if I cut-and-rearrange at a fine temporal grain, treating sound grains as phrases, I get into the realm of granulation. The transition into that space is interesting.
In order to measure amplitude I keep a running average of amplitude of the samples. I don't average every audio sample in Chuck because it would be too costly in CPU. Instead, I literally sample (in the statistical sense) the stream of samples.
How hard would this be to do in SC? I've seen reference to block processing, which I guess means that the audio engine processes audio samples in blocks. Would one have to write a unit generator attached to the audio stream to do this? Maybe there is one in a library that can already get at this data?
One reason I am asking now is that I think I am getting enough in a grant to buy a Kyma Pacarana, but I am not sure whether investing my time learning Kyma is the correct thing to do. If I take a summer to build up expertise in Chuck and/or SC, I can pass skills onto my students. Most of my students will never be buying Kyma engines.
Thanks.
Dale
_________________
When the stream is deep
my wild little dog frolics,
when shallow, she drinks. |
|
|
Back to top
|
|
|
dewdrop_world
Joined: Aug 28, 2006
Posts: 858
Location: Guangzhou, China
Audio files: 4
|
|
|
Back to top
|
|
|
dewdrop_world
Joined: Aug 28, 2006
Posts: 858
Location: Guangzhou, China
Audio files: 4
|
| Posted: Mon Dec 06, 2010 12:57 am Post subject:
|
|
|
| Acoustic Interloper wrote: | The original goal was rearrangement of spoken word passages based on grammar. The speaker does the "speech recognition," clicking buttons at phrase boundaries, which tell Chuck where to place boundaries for later rearrangement.
I found 2 things of interest: 1. Low amplitude transitions correlate with phrase boundaries, allowing me to avoid hitting the buttons by treating long pauses as phrase boundaries (this is good -- I tend to click too early or occasionally too late), and 2. if I cut-and-rearrange at a fine temporal grain, treating sound grains as phrases, I get into the realm of granulation. The transition into that space is interesting.
In order to measure amplitude I keep a running average of amplitude of the samples. I don't average every audio sample in Chuck because it would be too costly in CPU. Instead, I literally sample (in the statistical sense) the stream of samples.
How hard would this be to do in SC? I've seen reference to block processing, which I guess means that the audio engine processes audio samples in blocks. Would one have to write a unit generator attached to the audio stream to do this? Maybe there is one in a library that can already get at this data? |
SuperCollider has:
- An Amplitude UGen; can also calculate RMS using RunningSum (which is either in the main distribution or the sc3-plugins pack) -- why measure amplitude by statistical sampling when standard measures exist in the library already?
- A variety of onset-detector and feature-detector UGens (Onsets is probably the most feature complete, but other specific algorithms exist in their own UGens);
- SendReply, a UGen that sends custom OSC messages to the client -- you would use this e.g. when a boundary occurs, to store the boundaries in a language-side data structure*;
- Several built-in granulators -- some of them even give you control over the grain envelope (which can be chosen from a different buffer per grain!).
* Or you could save the boundaries into a server-side buffer, which may be more convenient to use with granular UGens but you'll have more flexibility in creating analytical metadata in the language. That is, the client would keep track of the grammar and pass information to the server for rendering.
I think you can do everything you have in mind using SC, with no need to write your own unit generators.
James
_________________
ddw online: http://www.dewdrop-world.net
sc3 online: http://supercollider.sourceforge.net |
|
|
Back to top
|
|
|
Acoustic Interloper
Joined: Jul 07, 2007
Posts: 2065
Location: Berks County, PA
Audio files: 89
|
| Posted: Mon Dec 06, 2010 3:16 pm Post subject:
|
|
|
Thanks, James!
Learning SC is definitely on my to do list. Planning for summer!
Take care.
_________________
When the stream is deep
my wild little dog frolics,
when shallow, she drinks. |
|
|
Back to top
|
|
|
bschiett
Joined: Jul 13, 2011
Posts: 79
Location: United States
|
| Posted: Wed Aug 10, 2011 5:01 am Post subject:
ugens in SC vs chuck |
|
|
Hi,
I haven't used chuck and SC before much, I'm mostly wondering what the current state is of the library of ugens in SC vs Chuchk? The few times i've played with SC it sounded great, and I'm thinking it has to do with the ugens. Unfortunately SC isn't really something you can easily link or embed with other software, and from what I understand chuck would be?
thanks
B
_________________
percussa mSSP - digital modular in a eurorack module - 8 in/4 out @ 48/96/192khz DC coupled - 25+ DSP modules https://www.kickstarter.com/projects/percussa/percussa-micro-super-signal-processor-eurorack-mod |
|
|
Back to top
|
|
|
Acoustic Interloper
Joined: Jul 07, 2007
Posts: 2065
Location: Berks County, PA
Audio files: 89
|
| Posted: Sat Aug 13, 2011 6:03 am Post subject:
Re: ugens in SC vs chuck |
|
|
| bschiett wrote: | | Unfortunately SC isn't really something you can easily link or embed with other software, and from what I understand chuck would be? |
James (Dewdrop World) can speak to SC much better than I, but both SC and ChucK support embedding using OSC and MIDI. We made use of it in a chess-to-music project a few years ago, with the chess game written in Python, and alternative back ends written in ChucK, SC and Max/MSP to generate sounds. A single OSC socket served whichever music back end was running.
I don't know the state of VST or similar APIs in either language, but SC seems pretty mature in a lot of ways. I am guessing that writing custom ugens is perhaps better supported in SC than in ChucK.
_________________
When the stream is deep
my wild little dog frolics,
when shallow, she drinks. |
|
|
Back to top
|
|
|
bschiett
Joined: Jul 13, 2011
Posts: 79
Location: United States
|
| Posted: Sat Aug 13, 2011 12:32 pm Post subject:
Re: ugens in SC vs chuck |
|
|
| Acoustic Interloper wrote: | | bschiett wrote: | | Unfortunately SC isn't really something you can easily link or embed with other software, and from what I understand chuck would be? |
James (Dewdrop World) can speak to SC much better than I, but both SC and ChucK support embedding using OSC and MIDI. We made use of it in a chess-to-music project a few years ago, with the chess game written in Python, and alternative back ends written in ChucK, SC and Max/MSP to generate sounds. A single OSC socket served whichever music back end was running.
I don't know the state of VST or similar APIs in either language, but SC seems pretty mature in a lot of ways. I am guessing that writing custom ugens is perhaps better supported in SC than in ChucK. |
thanks! I'll check out the possibilities in more detail ..
_________________
percussa mSSP - digital modular in a eurorack module - 8 in/4 out @ 48/96/192khz DC coupled - 25+ DSP modules https://www.kickstarter.com/projects/percussa/percussa-micro-super-signal-processor-eurorack-mod |
|
|
Back to top
|
|
|
Acoustic Interloper
Joined: Jul 07, 2007
Posts: 2065
Location: Berks County, PA
Audio files: 89
|
| Posted: Mon Aug 15, 2011 6:40 am Post subject:
|
|
|
Chapter 25 of the SuperCollider book is on *Writing Unit Generator Plug-ins* in C++ and associated config files. So, this is a hook within the SC server.
SC itself has two processes, client and server. The server does the heavy lifting, and communication between the two is via OSC. You can also use OSC to talk to a client process via the SC language, or directly to the server via its lower level protocol. Thus, embedding within a system seems well supported.
From what I can tell from ChucK's on-line documentation, it appears that you have to rebuild ChucK to add a ugen. The page at
http://chuck.cs.princeton.edu/doc/develop/
seems to be an outline only.
_________________
When the stream is deep
my wild little dog frolics,
when shallow, she drinks. |
|
|
Back to top
|
|
|
bschiett
Joined: Jul 13, 2011
Posts: 79
Location: United States
|
| Posted: Mon Aug 15, 2011 6:46 am Post subject:
|
|
|
| Acoustic Interloper wrote: | Chapter 25 of the SuperCollider book is on *Writing Unit Generator Plug-ins* in C++ and associated config files. So, this is a hook within the SC server.
SC itself has two processes, client and server. The server does the heavy lifting, and communication between the two is via OSC. You can also use OSC to talk to a client process via the SC language, or directly to the server via its lower level protocol. Thus, embedding within a system seems well supported.
From what I can tell from ChucK's on-line documentation, it appears that you have to rebuild ChucK to add a ugen. The page at
http://chuck.cs.princeton.edu/doc/develop/
seems to be an outline only. |
cool, thanks so much for the info!
_________________
percussa mSSP - digital modular in a eurorack module - 8 in/4 out @ 48/96/192khz DC coupled - 25+ DSP modules https://www.kickstarter.com/projects/percussa/percussa-micro-super-signal-processor-eurorack-mod |
|
|
Back to top
|
|
|
|
Forum index » DIY Hardware and Software » Supercollider
FAQ
Calendar
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Chat Room
