On-screen graphic widgets - such as FLTK offers - are well-nigh essential
for real-time Csound. So much so that unless FLTK or some other
cross-platform graphic capability were included in Csound5, we'd be pretty
much saying "no" to real-time usage.

Art Hunkins

----- Original Message -----
From: "Michael Gogins" 
To: 
Sent: Thursday, March 24, 2005 9:34 AM
Subject: Re: [Cs-dev] Broken again


> Your point about libary compatibility for precompiled packages is in
principle correct. This is a well-known problem and the Linux community is
working to address it with ABI standards. Nevertheless the problem is not
going away very soon.
>
> However, this is all somewhat theoretical. What are people's actual
experiences with installing Csound 5 with precompiled C++ on different
versions of Linux? I'm not talking about CsoundVST here, but about
widgets.cpp, fluidOpcodes, and cs4vst.
>
> Of course, I am always running csound 5 on the system that compiled it. On
Linux and Unix, I think it is considered acceptable to distribute a package
in the form of source code and expect the user to compile it, which resolves
this problem.
>
> However, I don't mean to minimize the problem. Users increasingly expect
precompiled packages, and especially for musicians this would be a big plus.
>
> I initially opposed having the FLTK widgets in the Csound distribution,
but I changed my mind because so many people seemed to find them useful or
even essential. I would not oppose their removal if the Csound 5 community
mostly agreed to remove them.
>
> My points about bugs and speed are separate issues.
>
> -----Original Message-----
> From: vanDongen/Gilcher 
> Sent: Mar 24, 2005 5:53 AM
> To: csound-devel@lists.sourceforge.net
> Subject: Re: [Cs-dev] Broken again
>
> On Tuesday 22 March 2005 15:27, Michael Gogins wrote:
>
> > In my view, Csound would contain fewer bugs and run slightly faster if
it
> > were coded entirely in C++. This view is based on experience and
> > experiments, not opinion. I am prepared to show code samples and
> > experimental results to support this view. I would of course be very
> > interested to review code samples and experimental results that
demonstrate
> > the opposite.
> >
>
> My experience is not very extensive, so please correct me if I am wrong.
> The biggest problem I have seen with C++ is binary incompatability
between
> libraries and applications using them. This is actually not that much of a
> problem for me, just the nuisance that upgrading the compiler means
> recompiling all my C++ libraries. And I don't upgrade my compiler that
> often :)
>
> But for distributing binaries of programs using a shared libcsound it is a
> real problem. The program won't run if it was compiled for a libcsound
> compiled differently. Even a different optimization flag will break binary
> compatibility I think. The only solution is to distribute a statically
linked
> private copy of libcsound with your application.
> So I think that the ambition of csound5 as a platform independent library
is
> best served by it being pure C.
>
> (And yes, I think including widgets in core Csound5 was/is a mistake. For
one
> thing it assumes that csound will only be run on general purpose pc's, and
> that as long as you support windows, Mac and linux you are cross platform.
My
> cell phone has a 400 MHz processor and stereo sound. Csound should run on
> that, and it will but without the widgets. Including C++ and widgets in
the
> core csound, will just create a forks for other uses. )
>
> Gerard
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
> Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
> Embedded(r) & Windows Mobile(tm) platforms, applications & content.
Register
> by 3/29 & save $300
http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
> Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
> Embedded(r) & Windows Mobile(tm) platforms, applications & content.
Register
> by 3/29 & save $300
http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Thu, 24 Mar 2005 12:18:09 -0500, Art Hunkins  wrote:

> On-screen graphic widgets - such as FLTK offers - are well-nigh essential
> for real-time Csound. So much so that unless FLTK or some other
> cross-platform graphic capability were included in Csound5, we'd be  
> pretty
> much saying "no" to real-time usage.
>
> Art Hunkins

huh?
Sorry, but I use csound as a realtime synthesis engine all the time  
without any widgets.
(of course I use it with a midi controller or inside pd)

Anyway, my point is that the widgets should not be in the engine, not that  
csound should not come with gui's.
An alternative:

Define control signal-i/o in a generic way in the engine and a seperate  
gui implementation/design tool to make the gui.
The gui would all be done by a front end.
Such a front end, could and should be included in the main csound  
distribution as a reference implementation.
It could include an  extension to the input files - or section in a csd -  
besides the orc and sco, defining the gui.
You can replace the gui file with another one, defining a different  
interface etc etc.
That is , of course, a lot of work.
Allowing for one thing, accesibility and exchange of interfaces for sight  
impaired musicians.
As I see it, the gui code was there, everybody wanted it, and nobody had  
or has the time to write a real alternative, including yours truly.
Obviously if I wanted it really badly, I should write the code :)

Gerard


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

That is a dangerous assumption. We just did a live techno show last 
night with nothing but csound, and zero screen output. The philosophy 
behind my software design for my real time rig is that everything should 
be controllable from midi controllers, and that if I need to reach for a 
mouse or look at a screen, then the interface is too slow. The computer 
sat on the floor.

That said, I think the FLTK stuff is cool, but is there any reason we 
could not have various packages, ie csound, csound + FLTK, etc? Would 
that just wind up being a logisitical nightmare? We can already compile 
it without fltk and python, etc so what about binary releases that are 
similar?

Iain


Art Hunkins wrote:
> On-screen graphic widgets - such as FLTK offers - are well-nigh essential
> for real-time Csound. So much so that unless FLTK or some other
> cross-platform graphic capability were included in Csound5, we'd be pretty
> much saying "no" to real-time usage.
> 
> Art Hunkins
> 
> ----- Original Message -----
> From: "Michael Gogins" 
> To: 
> Sent: Thursday, March 24, 2005 9:34 AM
> Subject: Re: [Cs-dev] Broken again
> 
> 
> 
>>Your point about libary compatibility for precompiled packages is in
> 
> principle correct. This is a well-known problem and the Linux community is
> working to address it with ABI standards. Nevertheless the problem is not
> going away very soon.
> 
>>However, this is all somewhat theoretical. What are people's actual
> 
> experiences with installing Csound 5 with precompiled C++ on different
> versions of Linux? I'm not talking about CsoundVST here, but about
> widgets.cpp, fluidOpcodes, and cs4vst.
> 
>>Of course, I am always running csound 5 on the system that compiled it. On
> 
> Linux and Unix, I think it is considered acceptable to distribute a package
> in the form of source code and expect the user to compile it, which resolves
> this problem.
> 
>>However, I don't mean to minimize the problem. Users increasingly expect
> 
> precompiled packages, and especially for musicians this would be a big plus.
> 
>>I initially opposed having the FLTK widgets in the Csound distribution,
> 
> but I changed my mind because so many people seemed to find them useful or
> even essential. I would not oppose their removal if the Csound 5 community
> mostly agreed to remove them.
> 
>>My points about bugs and speed are separate issues.
>>
>>-----Original Message-----
>>From: vanDongen/Gilcher 
>>Sent: Mar 24, 2005 5:53 AM
>>To: csound-devel@lists.sourceforge.net
>>Subject: Re: [Cs-dev] Broken again
>>
>>On Tuesday 22 March 2005 15:27, Michael Gogins wrote:
>>
>>
>>>In my view, Csound would contain fewer bugs and run slightly faster if
> 
> it
> 
>>>were coded entirely in C++. This view is based on experience and
>>>experiments, not opinion. I am prepared to show code samples and
>>>experimental results to support this view. I would of course be very
>>>interested to review code samples and experimental results that
> 
> demonstrate
> 
>>>the opposite.
>>>
>>
>>My experience is not very extensive, so please correct me if I am wrong.
>>The biggest problem I have seen with C++ is binary incompatability
> 
> between
> 
>>libraries and applications using them. This is actually not that much of a
>>problem for me, just the nuisance that upgrading the compiler means
>>recompiling all my C++ libraries. And I don't upgrade my compiler that
>>often :)
>>
>>But for distributing binaries of programs using a shared libcsound it is a
>>real problem. The program won't run if it was compiled for a libcsound
>>compiled differently. Even a different optimization flag will break binary
>>compatibility I think. The only solution is to distribute a statically
> 
> linked
> 
>>private copy of libcsound with your application.
>>So I think that the ambition of csound5 as a platform independent library
> 
> is
> 
>>best served by it being pure C.
>>
>>(And yes, I think including widgets in core Csound5 was/is a mistake. For
> 
> one
> 
>>thing it assumes that csound will only be run on general purpose pc's, and
>>that as long as you support windows, Mac and linux you are cross platform.
> 
> My
> 
>>cell phone has a 400 MHz processor and stereo sound. Csound should run on
>>that, and it will but without the widgets. Including C++ and widgets in
> 
> the
> 
>>core csound, will just create a forks for other uses. )
>>
>>Gerard
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
>>Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
>>Embedded(r) & Windows Mobile(tm) platforms, applications & content.
> 
> Register
> 
>>by 3/29 & save $300
> 
> http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
> 
>>_______________________________________________
>>Csound-devel mailing list
>>Csound-devel@lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
>>Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
>>Embedded(r) & Windows Mobile(tm) platforms, applications & content.
> 
> Register
> 
>>by 3/29 & save $300
> 
> http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
> 
>>_______________________________________________
>>Csound-devel mailing list
>>Csound-devel@lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

> huh?
> Sorry, but I use csound as a realtime synthesis engine all the time  
> without any widgets.
> (of course I use it with a midi controller or inside pd)

If you weren't on the other side of the world, I want to come see this!

> Define control signal-i/o in a generic way in the engine and a seperate  
> gui implementation/design tool to make the gui.
> The gui would all be done by a front end.
> Such a front end, could and should be included in the main csound  
> distribution as a reference implementation.
> It could include an  extension to the input files - or section in a csd 
> -  besides the orc and sco, defining the gui.
> You can replace the gui file with another one, defining a different  
> interface etc etc.

That's what I'm trying to do with those fl_controller and wx_controller 
examples that Michael and I made, I just haven't worked on them lately. 
I think a really cool way to do things would be to have a set of PD 
objects that could be used to directly access csound5 through api calls. 
One could then build guis really quickly in PD and unhinge them just as 
easily.

Iain


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

That would be the automation bus; I am trying to recall just how long ago it was 
I suggested it....

Richard Dobson

gerard van dongen wrote:
...
> Define control signal-i/o in a generic way in the engine and a seperate  
> gui implementation/design tool to make the gui.
> The gui would all be done by a front end.
...



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

This would also be the design of MacCsound. IMO, the API that Matt's
actually using should get synced up sometime with CS5.  There's a few
differences between the two at the moment.  The need for string labels
rather than indexes as well as being able to pass strings (in the
latest version) as well as number between host and csound are the two
differences I can think of at the top of my head.

steven


On Fri, 25 Mar 2005 00:39:11 +0000, Richard Dobson
 wrote:
> That would be the automation bus; I am trying to recall just how long ago it was
> I suggested it....
> 
> Richard Dobson
> 
> gerard van dongen wrote:
> ...
> > Define control signal-i/o in a generic way in the engine and a seperate
> > gui implementation/design tool to make the gui.
> > The gui would all be done by a front end.
> ...
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Would either one allow the api to set a named csound variable? Or is 
that just crazy talk? Sure would be handy, but I guess going through 
tables is not such a big hassle. For that matter, can the API handle 
named csound tables?

Iain

Steven Yi wrote:
> This would also be the design of MacCsound. IMO, the API that Matt's
> actually using should get synced up sometime with CS5.  There's a few
> differences between the two at the moment.  The need for string labels
> rather than indexes as well as being able to pass strings (in the
> latest version) as well as number between host and csound are the two
> differences I can think of at the top of my head.
> 
> steven
> 
> 
> On Fri, 25 Mar 2005 00:39:11 +0000, Richard Dobson
>  wrote:
> 
>>That would be the automation bus; I am trying to recall just how long ago it was
>>I suggested it....
>>
>>Richard Dobson
>>
>>gerard van dongen wrote:
>>...
>>
>>>Define control signal-i/o in a generic way in the engine and a seperate
>>>gui implementation/design tool to make the gui.
>>>The gui would all be done by a front end.
>>
>>...
>>
>>
>>-------------------------------------------------------
>>SF email is sponsored by - The IT Product Guide
>>Read honest & candid reviews on hundreds of IT Products from real users.
>>Discover which products truly live up to the hype. Start reading now.
>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>_______________________________________________
>>Csound-devel mailing list
>>Csound-devel@lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

.....I am trying to recall how long it is since it was implemented.....
==John ffitch
>>>>> "Richard" == Richard Dobson  writes:

 Richard> That would be the automation bus; I am trying to recall just
 Richard> how long ago it was I suggested it....

 Richard> Richard Dobson

 Richard> gerard van dongen wrote:
 Richard> ...
 >> Define control signal-i/o in a generic way in the engine and a seperate  
 >> gui implementation/design tool to make the gui.
 >> The gui would all be done by a front end.






-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Richard Dobson wrote:

> That would be the automation bus; I am trying to recall just how long 
> ago it was I suggested it....

Do you have a reasonably detailed specification for your automation
bus idea ?


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net