one sample block size vs demand rate
Hi guys, before we were talking about the differences between sc3 and chuck , and people said that in sc3 you cannot do one sample manipulation but i just discovered that sc3 has a group of ugens called "demand ugens" that allows to do one sample manipulation(one sample block). Do you guys know about this? What do you think about the posibilities of one sample block size in chuck vs demant rate posibilities in sc3? Are they both equivalent? or can you make things that you cannot do with the other? thanks in advance. R.
FWIW, Ronni, you can actually change the block size in SC to 1 sample. It takes a little bit of under-the-hood tweaking but a buddy of mine in grad school did some interesting things in SC using this technique. His project had to do with wavelet resynthesis, which required sub-sample calculations. http://doc.sccode.org/Reference/StartupFile.html Anyway, I get a weird feeling when people start to talk about the differences between audio programming systems in these terms. Whenever this performance comparison conversation starts (and it happens every fall ;) I always feel like it's a little off-base or simplistic or something. I think that's because the *major* differences between these systems are philosophical/architectural and not necessarily practical (in a general-purpose sense). For instance, there's a much closer coupling of program flow and synthesis for Chuck than SC. SC's language is slower, interpreted, much more expressive (and complicated) as a language, and is designed to hide the fact that it's main purpose is sending configuration and control messages to the node-based, highly performance-optimized sound server. Chuck, on the other hand, is designed to be fast enough to allow you to directly control the synthesis process during program execution. Control rates are determined by your own code and are, therefore, arbitrary. IMHO, Chuck's main evolution of these types of systems is the concurrency model, which is really brilliant. The closest thing I've ever seen to Chuck's model is that of Google's Go language, which is very young still also. As with all things, it's a trade-off. Each system does certain types of things better than others. If you add patching languages like Pd and Max to the conversation, it gets even more complicated. The answer to which system to use will always depend on the task at hand, your familiarity with the systems, and your personal preferences. More specifically, Chuck is a great language to experiment with single-sample block algorithms that you intend to then implement in C as a UGen (which could be added to any of the systems). </rant> Bored at work. Sorry. :) What is it that you're trying to do with single sample intervention? All best, Mike -- Michael Clemow http://michaelclemow.com http://abattoirprojects.com On Friday, August 31, 2012 at 11:05 AM, ronni montoya wrote:
Hi guys, before we were talking about the differences between sc3 and chuck , and people said that in sc3 you cannot do one sample manipulation but i just discovered that sc3 has a group of ugens called "demand ugens" that allows to do one sample manipulation(one sample block).
Do you guys know about this?
What do you think about the posibilities of one sample block size in chuck vs demant rate posibilities in sc3? Are they both equivalent? or can you make things that you cannot do with the other?
thanks in advance.
R. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu (mailto:chuck-users@lists.cs.princeton.edu) https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Ronni;
Do you guys know about this?
I didn't, thanks!
What do you think about the posibilities of one sample block size in chuck vs demant rate posibilities in sc3? Are they both equivalent? or can you make things that you cannot do with the other?
It seems to me that both are ways to attempt to efficiently (and as easily as possible) make trades between cpu usage and sound quality. This has been one of the big questions in computer music since CSound's "k rate". CSound's method is simple but not so flexible (improvements may have been made in recent years) and that flexibility is what ChucK's "advancing time" is more or less about. We make (IMHO) a good trade in that we add complexity but at the same time also open the way to new and powerful things, in particular that we can have a loop run at exactly one "beat", which may not be a integer number of samples in length, and that the rounding errors that this causes won't add up. The SC world is full of very clever people so I'm sure that their solutions will have comparable benefits. Yours, Kas.
participants (3)
-
Kassen
-
Michael Clemow
-
ronni montoya