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" 

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"
>

Hello Matt,

Does this mean that there will be an Intel MacCsound soon????  Hope  
so...
It would be incredibly useful to Mac-based Csound teachers - like me!

-dB


On Dec 5, 2007, at 6:54 PM, Matt J. Ingalls wrote:

>
> 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"

>
> Does this mean that there will be an Intel MacCsound soon????  Hope so...

i hope so too - this month.
   if it looks like it will be a pain at all, i think i am going 
to just try to get that CsoundX application (that's in the front ends 
in cvs) more robust.  i want to migrate to that eventually anyway because 
it uses cocoa (apple is gradually killing carbon) and users can design 
GUI with apple's free "interface builder" app and use any of apple's GUI 
widgets..

-m

I saw Matt demonstrate CsoundX at Sounds Electric and it looked great, 
it will be a great toolkit for building Csound applications.

Rory.


Matt J. Ingalls wrote:
> 
>>
>> Does this mean that there will be an Intel MacCsound soon????  Hope so...
> 
> i hope so too - this month.
>   if it looks like it will be a pain at all, i think i am going to just 
> try to get that CsoundX application (that's in the front ends in cvs) 
> more robust.  i want to migrate to that eventually anyway because it 
> uses cocoa (apple is gradually killing carbon) and users can design GUI 
> with apple's free "interface builder" app and use any of apple's GUI 
> widgets..
> 
> -m
> 
> 
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
> csound"
> 

Hi Matt,

What happened to the csound au plugin? Last time I checked it worked  
amazingly but didn't allow automation. Are you still developing it?  
It would be greatly useful :-)

Peiman

On 6 Dec 2007, at 00:10, Matt J. Ingalls wrote:

>
>>
>> Does this mean that there will be an Intel MacCsound soon????   
>> Hope so...
>
> i hope so too - this month.
>   if it looks like it will be a pain at all, i think i am going to  
> just try to get that CsoundX application (that's in the front ends  
> in cvs) more robust.  i want to migrate to that eventually anyway  
> because it uses cocoa (apple is gradually killing carbon) and users  
> can design GUI with apple's free "interface builder" app and use  
> any of apple's GUI widgets..
>
> -m
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"

i haven't touched it for a while, but it's still on the radar..
are you sure it didn't allow automation?  it should - but i think it was 
just like just 6 hardcoded channels and itwasn't a "synth" au so didn't 
take MIDI.

On Thu, 6 Dec 2007, Peiman Khosravi wrote:

> Hi Matt,
>
> What happened to the csound au plugin? Last time I checked it worked 
> amazingly but didn't allow automation. Are you still developing it? It would 
> be greatly useful :-)
>
> Peiman
>
> On 6 Dec 2007, at 00:10, Matt J. Ingalls wrote:
>
>> 
>>> 
>>> Does this mean that there will be an Intel MacCsound soon????  Hope 
>>> so...
>> 
>> i hope so too - this month.
>>   if it looks like it will be a pain at all, i think i am going to just 
>> try to get that CsoundX application (that's in the front ends in cvs) more 
>> robust.  i want to migrate to that eventually anyway because it uses cocoa 
>> (apple is gradually killing carbon) and users can design GUI with apple's 
>> free "interface builder" app and use any of apple's GUI widgets..
>> 
>> -m
>> 
>> 
>> 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"
>

Well maybe it was my au host. I have just got digital performer so I  
will try it with that and post back if it doesn't work. Glad to hear  
it's still on the go...

Also I mentioned bidule in a previous post. Bidule lets you open au  
plugins on the mac. It would be great to use csound in bidule (via  
csoundau) and assign external midi controllers very easily like that!

Thanks
Peiman

On 6 Dec 2007, at 00:25, Matt J. Ingalls wrote:

>
> i haven't touched it for a while, but it's still on the radar..
> are you sure it didn't allow automation?  it should - but i think  
> it was just like just 6 hardcoded channels and itwasn't a "synth"  
> au so didn't take MIDI.
>
> On Thu, 6 Dec 2007, Peiman Khosravi wrote:
>
>> Hi Matt,
>>
>> What happened to the csound au plugin? Last time I checked it  
>> worked amazingly but didn't allow automation. Are you still  
>> developing it? It would be greatly useful :-)
>>
>> Peiman
>>
>> On 6 Dec 2007, at 00:10, Matt J. Ingalls wrote:
>>
>>>> Does this mean that there will be an Intel MacCsound soon????   
>>>> Hope so...
>>> i hope so too - this month.
>>>   if it looks like it will be a pain at all, i think i am going  
>>> to just try to get that CsoundX application (that's in the front  
>>> ends in cvs) more robust.  i want to migrate to that eventually  
>>> anyway because it uses cocoa (apple is gradually killing carbon)  
>>> and users can design GUI with apple's free "interface builder"  
>>> app and use any of apple's GUI widgets..
>>> -m
>>> 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"

On Thu, 6 Dec 2007 Victor.Lazzarini@nuim.ie wrote:

> Gradually killing Carbon? Does it mean that we will have to learn
> Objective-C? When you thought that Apple learned things by
> adopting a unix-like system, they start messing it all over again...

well the official word is "Carbon isn't going away anytime soon" but they 
are not going to support 64bit, which probably means Carbon is 
stagnated, even in 32bit..

http://developer.apple.com/documentation/Carbon/Conceptual/Carbon64BitGuide/index.html

you can use C++ with objective-c, so i think a lot of developers just do 
GUI stuff in Objective-C/IB and handle everything else in C/C++

this probably will mean Csound's FLTK stuff won't work in 64-bit?

-m


>
> Victor
> ----- Original Message -----
> From: "Matt J. Ingalls" 
> Date: Thursday, December 6, 2007 12:12 am
> Subject: [Csnd] intel maccsound ( was teaching )
> To: csound@lists.bath.ac.uk
>
>>
>>>
>>> Does this mean that there will be an Intel MacCsound
>> soon????  Hope so...
>>
>> i hope so too - this month.
>>    if it looks like it will be a pain at all, i think
>> i am going
>> to just try to get that CsoundX application (that's in the front
>> ends
>> in cvs) more robust.  i want to migrate to that eventually
>> anyway because
>> it uses cocoa (apple is gradually killing carbon) and users can
>> design
>> GUI with apple's free "interface builder" app and use any of
>> apple's GUI
>> widgets..
>>
>> -m
>>
>>
>> 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"

But it means that we have to do Objective-C somewhere
along the line, which does not make me very happy. It's
worse than Microsoft trying to push C#

At 17:22 06/12/2007, you wrote:


>On Thu, 6 Dec 2007 Victor.Lazzarini@nuim.ie wrote:
>
>>Gradually killing Carbon? Does it mean that we will have to learn
>>Objective-C? When you thought that Apple learned things by
>>adopting a unix-like system, they start messing it all over again...
>
>well the official word is "Carbon isn't going away anytime soon" but they 
>are not going to support 64bit, which probably means Carbon is stagnated, 
>even in 32bit..
>
>http://developer.apple.com/documentation/Carbon/Conceptual/Carbon64BitGuide/index.html
>
>you can use C++ with objective-c, so i think a lot of developers just do 
>GUI stuff in Objective-C/IB and handle everything else in C/C++
>
>this probably will mean Csound's FLTK stuff won't work in 64-bit?
>
>-m
>
>
>>
>>Victor
>>----- Original Message -----
>>From: "Matt J. Ingalls" 
>>Date: Thursday, December 6, 2007 12:12 am
>>Subject: [Csnd] intel maccsound ( was teaching )
>>To: csound@lists.bath.ac.uk
>>
>>>
>>>>
>>>>Does this mean that there will be an Intel MacCsound
>>>soon????  Hope so...
>>>
>>>i hope so too - this month.
>>>    if it looks like it will be a pain at all, i think
>>>i am going
>>>to just try to get that CsoundX application (that's in the front
>>>ends
>>>in cvs) more robust.  i want to migrate to that eventually
>>>anyway because
>>>it uses cocoa (apple is gradually killing carbon) and users can
>>>design
>>>GUI with apple's free "interface builder" app and use any of
>>>apple's GUI
>>>widgets..
>>>
>>>-m
>>>
>>>
>>>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"

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

Victor Lazzarini wrote:
> But it means that we have to do Objective-C somewhere
> along the line, which does not make me very happy. It's
> worse than Microsoft trying to push C#
> 

It's not an entirely fair comparison, IMO. Apple didn't invent 
Objective-C - it was the language of the original NeXT GUI which they 
inherited when they bought NeXT - its family history includes Smalltalk. 
At the time, the NeXT was hailed by just about everyone who cared to 
comment, as being by far the easiest and best GUI to develop for.

I have yet to learn it, as I have yet to try making a native Mac Gui 
application, but will do sometime. I don't think Carbon is going away 
any time soon however; DAWs supporting Cocoa Audiounits are still, it 
seems, a minority.

Richard Dobson