He is better to program graphically (PD) or by text (Csound)? Somebody can describe the advantages of both? It is better Csound, Supercollider, Chuck, Nyquist? Thanks

i haven't used csound much, but one thing that intrigues me and i want to explore is using csound to create samples that i can in turn use in Pd. get the best of both worlds :-D
-ian

There's a [csound] object somewhere that will load a .orc and .sco

http://music.nuim.ie/musictec/csound/main.html

I haven't tried it properly, but if you have any luck let us know

wow! nice, thanks obi! i'll check it out when i get home
-ian

Csound seems to be more efficient in my experience. Obi, is this a fair statement? I'd be interested in the Csound/Pd combo as well. Could one go even farther than just triggering .sco files, and using the .orc's as basic synth modules inside of Pd?

I think it would be fairer to say thatl Pd is more 'efficient' than Csound. But to explain why it's necessary to explain why that's comparing screwdrivers to spanners a bit.
Csound was never designed as a real-time language. It came from an old Music V style design. As a very brief summary it's Barry Vercoes take on Max Mathews stuff that came out of a job based paradigm. It kinda got real-time by dint of computers getting faster while Miller took straight to a real-time approach because Pd came out of early versions of IRCAMS Max patcher which was more midi oriented. Same under the hood but with a subtle difference. In Csound you have i-time as well as two computation times krate and arate. Pd has the same duality but these are the message domain and the signal domain. Pd doesn't have i-time (initial time), but you can make it yourself by precomputing tables and then raising a DSP=1 to start the program going. In Csound these can be part of a "note" definition that lives in another file called the "score", while the patch is an "instrument" which is part of a collection called an "orchestra" file.. No score in Pd, Pd just sits there and listens for input or produces sounds by virtue of the message domain program it's running.
Because Csound doesn't have the same time constraints it can take longer and compute in more detail.

Csound has a lot of special functions, it makes use of library things that would be "external" in Pd. What it doesn't have that Pd has is the ability to make "abstractions", so that complex things can be built in terms of lots of simple things and shared, reused and deconstructed easily.

Where Csound triumphs is accuracy and detail of sound quality. You can ask Csound to produce "impossible" scores that would never run in Pd/Max and set it rendering overnight. It's a different approach to composition than the interactive one on which Puredata wins. Think of it as a games engine vs 3D Max. The sense of "Max", whatever that may be, is inverted.:)

How Csound achieves this is by design it can take as long as it wants to work something out. How Pd achieves its speed is that it uses practical approximations that will run in a guaranteed time. Pd is less accurate than Csound in most uses because it cuts some corners, but for the mostpart you don't hear these much.

This difference suggests two appropriate kinds of use. For design, interactive and real-time audio you would use Puredata. For final rendering of highly detailed soundscenes for a broadcast media like film you would render your ideas using Csound.

Hmm, so spanners and screwdrivers. But to answer the question, no, Pd is the more efficient, because it has to be, Or to use a car coordinate system Csound is possibly classier like a Merc, Bentley or Jaguar, while Pd is a Lamborghini or Aston Martin without being chavvy like a Lexus (Reaktor).:)

Reaktor? Chavvy?! I'm interested to hear more of your thoughts on the matter, Obi. I bought Reaktor a long while ago and never got under the hood, as the library instruments and effects are rather versatile. They do have a bit of a 'Reaktor sound' to them, though, which bugs me. But then, I'm a bit fussy about the 'fingerprints' of my software and hardware...

On that note, have you ever heard of anyone working on a Newscool-like sequencer in Pd based on living/multiplying/dying cells in a grid? I haven't even begun brainstorming about it, but it seems like it'd be fun to make and use.

Darrell

> Reaktor? Chavvy?! I'm interested to hear more of your thoughts on the matter, Obi.

LOL! pay no attention to my irreverant nose thumbing. Reaktor is a damn fine tool.

I bought in at version 1.8 or something and used it on loads of BBC radio 1 work. Then they brought in a dongle system that hosed it and voided most of my patches (no refund, no apology, no support), so any beef I have is with Native Instruments, not Reaktor.

Yes it does have "a sound", but most things do, even Pd I dare say. It's down to such things as the design of the most basic oscillators and filters that get used in every patch.

> have you ever heard of anyone working on a Newscool-like sequencer in Pd based on
> living/multiplying/dying cells in a grid?
> I haven't even begun brainstorming about it, but it seems like it'd be fun to make and use.

Yes, check the archives on "Life + Conway + Autonoma + Cellular + Miranda" I'm sure a few people have done this before.

a.

I can understand your issues with NI. I feel unduly bitten by their upgrade pricing, especially being a Reaktor user. Nevertheless, the money does appear to fund software development, so no complaints.

The characteristic sounds of any and all software and hardware come to grate on me with time. I can't decide if I should rotate my stock more often, or just work harder to exploit and derange each piece of kit without concern for the petty details. I may be procrastinating as well...

Yeah, that's probably it. Thanks for the living seq info.

Darrell

obi you mentioned some environments for building plugins. I have done some reading on faust. Perhaps you could elaborate on some of those.
I was considering exploring some of these for DSP purposes. I am going to be processing a number of audio streams simultaneously. I was thinking it might be more efficient to code a few externals and then wire em together in PD, rather than doing everything in PD. I don't know much about how PD works under the hood. Perhaps this idea is un-necessary.
any info would be cool.

I have done some C++ if that helps.

Flext is another good development aid in C++ because you can create Max and Pd externs from the same code.

Faust takes this to an extreme. You write code in a pseudo algebra and it has a bunch of transformers/templates that can make VST plugins, LADSPA, Max and Pd externs or stand alone applications, very nice!

I haven't done amazing things with it, too busy wrtiting in Pd atm, but it is a useful tool.

Also been talking to a chap called Rurik lately who made some VSTs doing similar things to my sound effects, but he chooses SynthEdit for his work. Unfortunately I don't think it can export Pd or Max externs, just VSTs.

I would try doing whatever you want in plain Pd first and only go to externals if

It isn't fast enough
ii) You hit a programming problem that is very inelegant in Pd but easy in C

I think Csound is oldest than Pd. Csound ids generation type of music-N, you need two file first is orchestra file for design your generator and second is instrumen file there is have ftable and controlling for variable and parameter instrument

Digging up an old thread...

obi, you mentioned:

"...How Pd achieves its speed is that it uses practical approximations that will run in a guaranteed time. Pd is less accurate than Csound in most uses because it cuts some corners, but for the mostpart you don't hear these much..."

I'm fascinated to learn precisely what the approximations and corners the pd employs. Are you able to elaborate?

@Osc~ I've heard that PD uses cheap wave tables for oscillators. C Sound and SC people are always bragging on their "superior" oscillators.

Not sure on the details, but that could be one thing.

setting the wavetable for the oscili opcode is left entirely up to the user, so one can create a table that is 2^16 (65536 samples) and fill it with a sine wave. Larger tables tend to alias less, or at least aliasing starts to occur at relatively higher frequencies. This is also affected by the interpolation the opcode employs - 4 point cubic, 6 point hermite etc. Pd uses 4-point interpolation at its best by default, but this doesn't mean that an external can't be used, in fact check this thread: http://lists.puredata.info/pipermail/pd-list/2008-07/063475.html

Equally in csound you can use the cheapest opcodes and smallest tables and it sounds particularly guff.

I can't really see a reason why Pd can't produce a hifi sound as good as Csound. THe trade off for realtime audio performance is that there are some minimal quality reductions in certain areas to save on cpu, but that doesn't mean you intrinsically can't recoup those savings...

I'm no dsp guru or a dsp developer per se; maybe someone could chime in an correct me? But I've used other environments and read a lot over the years

My personal experience is just that Csound comes with more sound generators and fancy effects/processors/etc. (there's no Csound-extended; they just add stuff if they think someone will like it). So it's easy to get something sounding better if there's already pre-built band-limited oscillators to work with. In Pd, you have to built them or find one someone else built. But as boonier said, there's plenty of cheap crap in Csound, too, and if you use opcodes that are direct analogues to Pd objects, any difference in sound will likely be negligible.

Incidentally the first bandlimited oscillators that spring to mind are the blosc~ family in the creb library. They cover square and sawtooth, but it would be nice if they extended to triangle. THere are other sets I believe tho...