If you mean better realtime control within the orchestra, I think Csound may 
well be better than PD now. At a minimum, you have a choice of the number of 
audio sample frames per control sample, which as far as I recall, PD does 
not. Also we now have multiple facilities (channel opcodes, callbacks, FLTK 
opcodes, OSC, mixer opcodes) for controlling things at krate.

Regards,
Mike

----- Original Message ----- 
From: "Matt J. Ingalls" 
To: 
Sent: Wednesday, December 05, 2007 6:54 PM
Subject: [Csnd] Re: Re: teaching csound: textbook, PD, etc


>
> well of course i am teaching using MacCsound, which is easier to use than 
> all your examples :)  anyway, the quote was "better realtime control" - 
> which i assumed was something other than GUI widgets...
>
> -m
>
> On Wed, 5 Dec 2007, Michael Gogins wrote:
>
>> PD has better support for real-time interaction, in that the PD patches 
>> are the orchestra language, so once you create a patch, you can control 
>> it in real time without needing to do more work.
>>
>> As you of course know, Csound is quite adequate for real-time control of 
>> audio though it does lack PD's jitter stuff for video. On canonical 
>> Csound, you can use the FLTK opcodes, or you can use an external Python 
>> GUI toolkit (which work very well), or you can use OSC. But of course, 
>> with canonical Csound all this visual stuff is another layer of 
>> programming, even FLTK. PD doesn't have this extra step.
>>
>> I do find that programming GUIs in Python using the channel opcodes and 
>> binding them to global variables in the orchestra is quite 
>> straightforward and I do not think it would be hard to teach. I have used 
>> Boa Constructor with success as a rapid application development system 
>> for building forms to control Csound.
>>
>> Regards,
>> Mike
>>
>> ----- Original Message ----- From: "Matt J. Ingalls" 
>> To: 
>> Sent: Wednesday, December 05, 2007 5:47 PM
>> Subject: [Csnd] teaching csound: textbook, PD, etc
>>
>>
>>>
>>> well i'm starting to think about my class (inherited from Jim Hearon) in 
>>> the spring -- it has been acoustics & synthesis using Csound and 
>>> whatever freeware audio editor is available (the school will NOT 
>>> purchase any software) - using the Dodge as a textbook.
>>>
>>> but at least right now i'm feeling this all is so "old school" and was 
>>> wondering if any of you out there have any opinions on teaching, 
>>> software, or textbooks?
>>>
>>> of course PD and Miller Puckette's new book is the first alternative 
>>> that comes to mind..  however at first glance i see the first page 
>>> starts with the equation of a sine wave
>>> and that's not going to go over well with my students..
>>>
>>> i also see that he says:
>>>
>>> "Csound is better adapted
>>> than Pd for batch processing and it handles polyphony much better than
>>> Pd does. On the other hand, Pd has a better developed real-time control
>>> structure than Csound."
>>>
>>> is that last statement really true (anymore)?
>>>
>>>
>>> thanks,
>>> matt
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
>>> csound"
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
>> csound"
>>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
> csound" 

Michael Gogins wrote:
> If you mean better realtime control within the orchestra, I think 
> Csound may well be better than PD now. At a minimum, you have a choice 
> of the number of audio sample frames per control sample, which as far 
> as I recall, PD does not. Also we now have multiple facilities 
> (channel opcodes, callbacks, FLTK opcodes, OSC, mixer opcodes) for 
> controlling things at krate.
>
PD's krate is effectively determined by the audio block size, as all the 
messages are processed in between blocks (some objects can resolve 
samples within blocks but their output is always synced to the block 
size). The block size can go right down to single sample frames, so if 
your machine is fast enough to process all the inter-object messages and 
the audio you should be able to have krate= arate on pd as well. It 
would be interesting to see some measurements of audio latency using pd, 
pd and csoundapi~, and csound, with MIDI or OSC or keyboard/mouse 
interfaces.

Martin

Hi,
Someone correct me if I'm wrong, but I'm under the impression that
control rate events in pure data are "time stamped" in relation to the
audio buffer, resulting in more precise control. I'm not sure if this
statement is actually true, but I would really like it to be true for
csound....

Cheers,
Andrés

El jue, 06-12-2007 a las 08:58 +0200, Chuckk Hubbard escribió: 
> On Dec 6, 2007 3:47 AM, Michael Gogins  wrote:
> > If you mean better realtime control within the orchestra, I think Csound may
> > well be better than PD now. At a minimum, you have a choice of the number of
> > audio sample frames per control sample, which as far as I recall, PD does
> > not. Also we now have multiple facilities (channel opcodes, callbacks, FLTK
> > opcodes, OSC, mixer opcodes) for controlling things at krate.
> 
> Pd does have the [block~] and [switch~] objects, which may have
> arguments, or be sent them, for locally changing audio frames per
> block as well as FFT size.  It may have any number of control values
> per block, but they can only be read from user input once per block;
> so it's more communication rate than control rate.  The [line] object,
> for instance, is not audio, but its internal time grain can be set
> independently with arguments.  The [switch~] object can turn local
> audio processing on and off as well as changing block size.
> I believe audio output within reblocked subpatches is a big problem
> for Pd.  Audio must be passed directly to other patches with default
> block size to be heard.
> Going over this, it occurs to me Csound's reference source is far
> easier to use; every Pd help patch has a different format, and some
> things are not fully explained.
> 
> -Chuckk
> 
> 
> >
> > Regards,
> > Mike
> >
> > ----- Original Message -----
> > From: "Matt J. Ingalls" 
> > To: 
> >
> > Sent: Wednesday, December 05, 2007 6:54 PM
> > Subject: [Csnd] Re: Re: teaching csound: textbook, PD, etc
> >
> >
> > >
> > > well of course i am teaching using MacCsound, which is easier to use than
> > > all your examples :)  anyway, the quote was "better realtime control" -
> > > which i assumed was something other than GUI widgets...
> > >
> > > -m
> > >
> > > On Wed, 5 Dec 2007, Michael Gogins wrote:
> > >
> > >> PD has better support for real-time interaction, in that the PD patches
> > >> are the orchestra language, so once you create a patch, you can control
> > >> it in real time without needing to do more work.
> > >>
> > >> As you of course know, Csound is quite adequate for real-time control of
> > >> audio though it does lack PD's jitter stuff for video. On canonical
> > >> Csound, you can use the FLTK opcodes, or you can use an external Python
> > >> GUI toolkit (which work very well), or you can use OSC. But of course,
> > >> with canonical Csound all this visual stuff is another layer of
> > >> programming, even FLTK. PD doesn't have this extra step.
> > >>
> > >> I do find that programming GUIs in Python using the channel opcodes and
> > >> binding them to global variables in the orchestra is quite
> > >> straightforward and I do not think it would be hard to teach. I have used
> > >> Boa Constructor with success as a rapid application development system
> > >> for building forms to control Csound.
> > >>
> > >> Regards,
> > >> Mike
> > >>
> > >> ----- Original Message ----- From: "Matt J. Ingalls" 
> > >> To: 
> > >> Sent: Wednesday, December 05, 2007 5:47 PM
> > >> Subject: [Csnd] teaching csound: textbook, PD, etc
> > >>
> > >>
> > >>>
> > >>> well i'm starting to think about my class (inherited from Jim Hearon) in
> > >>> the spring -- it has been acoustics & synthesis using Csound and
> > >>> whatever freeware audio editor is available (the school will NOT
> > >>> purchase any software) - using the Dodge as a textbook.
> > >>>
> > >>> but at least right now i'm feeling this all is so "old school" and was
> > >>> wondering if any of you out there have any opinions on teaching,
> > >>> software, or textbooks?
> > >>>
> > >>> of course PD and Miller Puckette's new book is the first alternative
> > >>> that comes to mind..  however at first glance i see the first page
> > >>> starts with the equation of a sine wave
> > >>> and that's not going to go over well with my students..
> > >>>
> > >>> i also see that he says:
> > >>>
> > >>> "Csound is better adapted
> > >>> than Pd for batch processing and it handles polyphony much better than
> > >>> Pd does. On the other hand, Pd has a better developed real-time control
> > >>> structure than Csound."
> > >>>
> > >>> is that last statement really true (anymore)?
> > >>>
> > >>>
> > >>> thanks,
> > >>> matt
> > >>>
> > >>>
> > >>> Send bugs reports to this list.
> > >>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> > >>> csound"
> > >>
> > >>
> > >>
> > >> Send bugs reports to this list.
> > >> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> > >> csound"
> > >>
> > >
> > >
> > > Send bugs reports to this list.
> > > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> > > csound"
> >
> >
> >
> > Send bugs reports to this list.
> > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> >
> 
> 
> 

Andres Cabrera wrote:
>Hi,
>Someone correct me if I'm wrong, but I'm under the impression that
>control rate events in pure data are "time stamped" in relation to the
>audio buffer, resulting in more precise control. I'm not sure if this
>statement is actually true, but I would really like it to be true for
>csound....

In PD the [block~] object can be used to set the audio block size in the 
current patcher window, so you could have different block sizes running at 
the same time. There is no overall time-stamp, it's just that the control 
messages are processed in between audio blocks.

Martin

yes, there is no advantage there. Eric Lyon actually wrote
a load of control classes which produce audio-rate data to
allow precise timing. But that is just like running a-rate controls
in  Csound.

Victor

At 16:01 06/12/2007, you wrote:
>Andres Cabrera wrote:
>>Hi,
>>Someone correct me if I'm wrong, but I'm under the impression that
>>control rate events in pure data are "time stamped" in relation to the
>>audio buffer, resulting in more precise control. I'm not sure if this
>>statement is actually true, but I would really like it to be true for
>>csound....
>
>In PD the [block~] object can be used to set the audio block size in the 
>current patcher window, so you could have different block sizes running at 
>the same time. There is no overall time-stamp, it's just that the control 
>messages are processed in between audio blocks.
>
>Martin
>
>
>
>
>Send bugs reports to this list.
>To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
>csound"

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth