Rendering is not done by MacCsound but by Csound, so that
should be the same, or in fact faster, since QuteCsound runs the
native intel Csound. I can't see that this can be more sluggish.

As far as I can see, at least on Windows, QuteCsound is great and
works very well, not sluggish at all. I think it is excellent that it uses
an open GUI framework that can be maintained for all platforms.
Andres did a sterling job with it and the compatibility with MacCsound
was a good idea, although it could have restricted the design of
the program. But it makes all those MacCsound examples now
multiplatform.

Again, I think this is absolutely great. Perhaps soon we would be able
to substitute the troublesome Csound5GUI by QuteCsound in the
distribution, if Andres thinks it is a good idea.

(well, there is one thing I am personally not too keen: its name,
also awkward to spell and type... :)

Victor

----- Original Message ----- 
From: "Darren Nelsen" 
To: 
Sent: Thursday, January 08, 2009 5:12 AM
Subject: [Csnd] Re: RE: Re: RE: Mac Leopard


> On Jan 7, 2009, at 10:15 PM, Matt Ingalls wrote:
>
>> QuteCsound looks great, but as far as i can tell it still has a ways  to 
>> go and seems more sluggish.
>
> It is more sluggish.
>
> I don't know what magic you did in MacCsound, but it renders most 
> efficiently. :)
>
> Darren
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
> csound" 

Now all we need is a version that runs under Intel mac installation of  
csound that installs with an installed macpython and we'll be able to  
do some cookin'.
Or is that now possible - I'm afraid I'm out of touch....

David
On 08/01/2009, at 8:18 PM, victor wrote:

> Rendering is not done by MacCsound but by Csound, so that
> should be the same, or in fact faster, since QuteCsound runs the
> native intel Csound. I can't see that this can be more sluggish.
>
> As far as I can see, at least on Windows, QuteCsound is great and
> works very well, not sluggish at all. I think it is excellent that  
> it uses
> an open GUI framework that can be maintained for all platforms.
> Andres did a sterling job with it and the compatibility with MacCsound
> was a good idea, although it could have restricted the design of
> the program. But it makes all those MacCsound examples now
> multiplatform.
>
> Again, I think this is absolutely great. Perhaps soon we would be able
> to substitute the troublesome Csound5GUI by QuteCsound in the
> distribution, if Andres thinks it is a good idea.
>
> (well, there is one thing I am personally not too keen: its name,
> also awkward to spell and type... :)
>
> Victor
>
> ----- Original Message ----- From: "Darren Nelsen"  >
> To: 
> Sent: Thursday, January 08, 2009 5:12 AM
> Subject: [Csnd] Re: RE: Re: RE: Mac Leopard
>
>
>> On Jan 7, 2009, at 10:15 PM, Matt Ingalls wrote:
>>
>>> QuteCsound looks great, but as far as i can tell it still has a  
>>> ways  to go and seems more sluggish.
>>
>> It is more sluggish.
>>
>> I don't know what magic you did in MacCsound, but it renders most  
>> efficiently. :)
>>
>> Darren

I think it does run under Intel Macs, does it not?

At 11:19 08/01/2009, you wrote:
>Now all we need is a version that runs under Intel mac installation of
>csound that installs with an installed macpython and we'll be able to
>do some cookin'.
>Or is that now possible - I'm afraid I'm out of touch....
>
>David
>On 08/01/2009, at 8:18 PM, victor wrote:
>
>>Rendering is not done by MacCsound but by Csound, so that
>>should be the same, or in fact faster, since QuteCsound runs the
>>native intel Csound. I can't see that this can be more sluggish.
>>
>>As far as I can see, at least on Windows, QuteCsound is great and
>>works very well, not sluggish at all. I think it is excellent that
>>it uses
>>an open GUI framework that can be maintained for all platforms.
>>Andres did a sterling job with it and the compatibility with MacCsound
>>was a good idea, although it could have restricted the design of
>>the program. But it makes all those MacCsound examples now
>>multiplatform.
>>
>>Again, I think this is absolutely great. Perhaps soon we would be able
>>to substitute the troublesome Csound5GUI by QuteCsound in the
>>distribution, if Andres thinks it is a good idea.
>>
>>(well, there is one thing I am personally not too keen: its name,
>>also awkward to spell and type... :)
>>
>>Victor
>>
>>----- Original Message ----- From: "Darren Nelsen" 
>>To: 
>>Sent: Thursday, January 08, 2009 5:12 AM
>>Subject: [Csnd] Re: RE: Re: RE: Mac Leopard
>>
>>
>>>On Jan 7, 2009, at 10:15 PM, Matt Ingalls wrote:
>>>
>>>>QuteCsound looks great, but as far as i can tell it still has a
>>>>ways  to go and seems more sluggish.
>>>
>>>It is more sluggish.
>>>
>>>I don't know what magic you did in MacCsound, but it renders most
>>>efficiently. :)
>>>
>>>Darren
>
>
>
>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 

On 08/01/2009, at 10:53 PM, Victor Lazzarini wrote:

> I think it does run under Intel Macs, does it not?
>
> At 11:19 08/01/2009, you wrote:
>> Now all we need is a version that runs under Intel mac installation  
>> of
>> csound that installs with an installed macpython and we'll be able to
>> do some cookin'.
>> Or is that now possible - I'm afraid I'm out of touch....
>>
>> David
>>

from earlier:

> Hi David,
>
> If this happens you probably have a version of Csound installed which
> is incompatible with QuteCsound. Make sure you have the Intel version
> of Csound installed. Another important thing is that QuteCsound
> requires Csound >= 5.09. QuteCsound is currently compatible with the
> floats build only, unless you build from source (not currently an
> issue since 5.10 is not out yet).
>
> Cheers,
> Andrés
>
> On Sat, Dec 20, 2008 at 8:56 PM, DavidW  wrote:
>> Hi Andres,
>> I download and unpack
>> QuteCsound-0.4RC1-r110-OSX-Intel-incQt.tar
>>
>> resulting in a file qutecsound.app
>> double-click and it tries to load and then "quits unexpectedly"
>>
>>
>> i couldn't find any documentation. - what's the trick?
>>
>> David
>> Intel OSX 10.5.6
>

On Jan 8, 2009, at 4:18 AM, victor wrote:

> Rendering is not done by MacCsound but by Csound, so that
> should be the same, or in fact faster, since QuteCsound runs the
> native intel Csound. I can't see that this can be more sluggish.

I understand, but the GUIs have overhead. The same file 'rendered' (or  
perhaps I should say launched) in realtime by MacCsound and  
QuteCsound... the MacCsound one sounds near perfectly clean, the  
QuteCsound has choppy output. I have tried many settings in Qute  
(Csound API vs. external shell, Run in separate thread, etc.) without  
much luck. Qute's got a lot of potential, but it doesn't perform as  
well as MacCsound on my machine (G5 PowerPC).

Perhaps more of an issue of portaudio VS. Matt's own audio IO code (which
might be adopted by QuteCsound on the Mac? Perhaps Andres can ask Matt).

At 13:04 08/01/2009, you wrote:
>On Jan 8, 2009, at 4:18 AM, victor wrote:
>
>>Rendering is not done by MacCsound but by Csound, so that
>>should be the same, or in fact faster, since QuteCsound runs the
>>native intel Csound. I can't see that this can be more sluggish.
>
>I understand, but the GUIs have overhead. The same file 'rendered' (or
>perhaps I should say launched) in realtime by MacCsound and
>QuteCsound... the MacCsound one sounds near perfectly clean, the
>QuteCsound has choppy output. I have tried many settings in Qute
>(Csound API vs. external shell, Run in separate thread, etc.) without
>much luck. Qute's got a lot of potential, but it doesn't perform as
>well as MacCsound on my machine (G5 PowerPC).
>
>
>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 

the code i use in MacCsound is pretty old and i think apple recommends using the defaultaudiounit or whatever its called now.

i started working on using this, with the CsoundX application, which is in the sorceforge sources under "front ends"  -- as i recall there was still some things to do with multichannel and different sample rates, but i think it is better than MacCsound.

-m

________________________________________
From: Victor Lazzarini [Victor.Lazzarini@nuim.ie]
Sent: Thursday, January 08, 2009 5:07 AM
To: csound@lists.bath.ac.uk
Subject: [Csnd] Re: Re: QuteCsound is great (was Re:  Mac Leopard)

Perhaps more of an issue of portaudio VS. Matt's own audio IO code (which
might be adopted by QuteCsound on the Mac? Perhaps Andres can ask Matt).

At 13:04 08/01/2009, you wrote:
>On Jan 8, 2009, at 4:18 AM, victor wrote:
>
>>Rendering is not done by MacCsound but by Csound, so that
>>should be the same, or in fact faster, since QuteCsound runs the
>>native intel Csound. I can't see that this can be more sluggish.
>
>I understand, but the GUIs have overhead. The same file 'rendered' (or
>perhaps I should say launched) in realtime by MacCsound and
>QuteCsound... the MacCsound one sounds near perfectly clean, the
>QuteCsound has choppy output. I have tried many settings in Qute
>(Csound API vs. external shell, Run in separate thread, etc.) without
>much luck. Qute's got a lot of potential, but it doesn't perform as
>well as MacCsound on my machine (G5 PowerPC).
>
>
>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



Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

i was unaware of a change in the API - guess i should read this list more often..

________________________________________
From: Andres Cabrera [mantaraya36@gmail.com]
Sent: Thursday, January 08, 2009 5:49 AM
To: csound@lists.bath.ac.uk
Subject: [Csnd] Re: Re: QuteCsound is great (was Re: Mac Leopard)

Try it. QuteCsound will use the Csound that is installed, so if it's
5.09 or greater, it should work.

BTW, now thinking about the API version change, would this not break
MacCsound for 5.10 onwards?

Cheers,
Andrés

On Thu, Jan 8, 2009 at 6:19 AM, DavidW  wrote:
> Now all we need is a version that runs under Intel mac installation of
> csound that installs with an installed macpython and we'll be able to do
> some cookin'.
> Or is that now possible - I'm afraid I'm out of touch....
>
> David
> On 08/01/2009, at 8:18 PM, victor wrote:
>
>> Rendering is not done by MacCsound but by Csound, so that
>> should be the same, or in fact faster, since QuteCsound runs the
>> native intel Csound. I can't see that this can be more sluggish.
>>
>> As far as I can see, at least on Windows, QuteCsound is great and
>> works very well, not sluggish at all. I think it is excellent that it uses
>> an open GUI framework that can be maintained for all platforms.
>> Andres did a sterling job with it and the compatibility with MacCsound
>> was a good idea, although it could have restricted the design of
>> the program. But it makes all those MacCsound examples now
>> multiplatform.
>>
>> Again, I think this is absolutely great. Perhaps soon we would be able
>> to substitute the troublesome Csound5GUI by QuteCsound in the
>> distribution, if Andres thinks it is a good idea.
>>
>> (well, there is one thing I am personally not too keen: its name,
>> also awkward to spell and type... :)
>>
>> Victor
>>
>> ----- Original Message ----- From: "Darren Nelsen" 
>> To: 
>> Sent: Thursday, January 08, 2009 5:12 AM
>> Subject: [Csnd] Re: RE: Re: RE: Mac Leopard
>>
>>
>>> On Jan 7, 2009, at 10:15 PM, Matt Ingalls wrote:
>>>
>>>> QuteCsound looks great, but as far as i can tell it still has a ways  to
>>>> go and seems more sluggish.
>>>
>>> It is more sluggish.
>>>
>>> I don't know what magic you did in MacCsound, but it renders most
>>> efficiently. :)
>>>
>>> Darren
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>



--


Andrés


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

> I strived for MacCsound compatibility primarily because it's the main
> and most sucessful implementation of realltime widgets for Csound. I
> wish Matt had used a more extensible and robust system like xml,

i like Rory's lettuce/cabbage -- and had started talking to him about adding a few things so that everything MacCsound does could be specified in his spec.. 
i also had a proposal of replacing the FLTK opcodes with a kind of system with widgets that would by fully dynamically changeable with a standardized system of attributes system sent with "outvalue" (or something similar) so you could do something like this at krate:

outwidget iSliderChan, "Value", .56
outwidget iSliderChan, "Label", "the new slider name"


but never quite thought it all the way through and basically dropped the ball..

> Hi Matt, happy new year!

hey Rory - likewise!

> interchangeable across frontends, plus it would do away with frontend

and the front ends could use the communication system too to generate/modify widgets on the fly.  


> specific widgets syntax which in most cases is pretty ugly..

although still would need to have some kind of syntax to save initial layout to file, right?

On 09/01/2009, at 7:22 AM, Michael Gogins wrote:

> Long experience teaches me that code is superior to XML. The ideal
> would be a single language in which one could write the GUI, the
> software orchestra, and the score generator
Hi Mike!
"ideal", perhaps but, IMO,  a practical disaster.
The more ways that csound can communicate from its exclusive country  
residence with the rest of the world, the more it will be supported.

> ....
>  (Actually of course you can write
> everything including the GUI and score generator in the Csound
> orchestra language, but it's a more awkward language than Python.)

How do we do database management?
multidimensional array processing - take a simple outer product for eg?
What about processing html-embedded data?
We could all write opcodes to do lots of things - but at what cost?

> Do not underestimate the time wasted by switching languages, switching
> editors, and switching mental gears.
>
On the other hand, do not underestimate the amount of waste in  
learning to drive a racing car that you then find you have to leave in  
the garage because you can't drive it on the street.

Happy New Ears everyone,
David

> I'm not realy sure if having the widgets inside the actual orc is
> convenient. I think it's best as it is right now, with the widgets as

in general i agree (this was in addition to some other definition)
but this solution was really directed at getting a generic system to replace FLTK
also having the possibility of having the orc dynamically generate/modify the GUI 
was cool..

> solution would make the system harder to extend, as adding
> functionality would break API compatibility.

there are a number of ways to do this without changing the API