There are two models here:

One, distribute a front end or front ends with the Csound installers.

Two, people distribute their own front ends from their own Web sites and 
with their own installers, built with the Csound API.

In case one, I don't see an advantage to having many front ends in one 
installer. In this case I do think there should be a "standard" just as I 
think there should be a standard Csound 5. I think this front end should be 
fairly simple, at least to start with.

In case two, the more, the merrier. This is one of the reasons I wanted 
there to be an API in the first place. And, I don't have to spend my time 
maintaining these front ends, and people can create the features THEY need 
and want. Over time, the various front end features that people like can be 
incorporated in the "standard" or, conversely, if an independent front end 
proves wildly popular it can simply be adopted as the standard, replacing 
the earlier one.

Regards,
Mike


----- Original Message ----- 
From: "David Ogborn" 
To: 
Sent: Thursday, April 27, 2006 9:23 PM
Subject: Re: [Cs-dev] Re: [Csnd] Csound 5 GUI frontends


> Hello Michael, John and csound-devel list,
>
> I think that the fact that Csound 5 does not come with any particular
> front-end, far from representing a liability is in fact an advantage.
> It encourages the independent development of multiple "front-ends" to
> reflect the great diversity of work processes employed by a great
> diversity of electronic sound artists.
>
> I wonder what the community would gain by a certain front-end being
> declared as the "standard" front-end.  Why not distribute all front-ends
> as separate programs with Csound 5 as their major/only prerequisite?
>
> Yours truly,
> David
>
> Michael Gogins wrote:
>> I've played with your frontend, and looked a little bit at the sources.
>>
>> Basically, I like what you have done.  I like the transport controls and
>> time counter, I think this is very useful, not least because its
>> function will be obvious to musicians who are not programmers. I also
>> like the fields for adding soundfile ID tags.
>>
>> I suggest that we combine CsoundVST and your GUI to make a standard
>> frontend for Csound 5. I think this can be done in a way that would
>> please both those who do not wish to install Python and those who do,
>> reduce duplication of effort, and make Csound 5 more maintainable.
>>
>> First, allow me to point out some minor problems, then I will make some
>> suggestions.
>>
>> The first problem is that there is a black console window, then there is
>> a second console window (with a white background) for Csound messages.
>> The first window can be omitted with the right linker flag, I think.
>> Probably, you have just left this in for debugging purposes.
>>
>> The second problem is that configuration dialog has no "close" button
>> (though Alt-F4 does close it), and it's a modal dialog so when it's
>> open, you can't run Csound. This is obviously easy to fix in FLTK.
>>
>> I think it might be a problem that you construct the Csound command line
>> entirely from dialogs. Perhaps there should also be a text field for
>> additional flags by hand?
>>
>> Now for my suggestions.
>>
>> The main suggestion is to allow, but not require, the frontend to use
>> Python.  This can be done by (a) calling Python via dl_open and dl_sym
>> (or the Windows equivalents) instead of linking statically, and (b) by
>> changing the Python Csound API to permit plugging an existing instance
>> of Csound into Python (CsoundVST does it the other way round, creates
>> Csound in Python then extracts it for the GUI). This would enable Csound
>> operated via Python to print messages to the console, operate the time
>> counter, etc. In other words, if the frontend can load the Python
>> library, it will unhide a script editing button and plug its already
>> created instance of Csound into Python. If the script field is
>> populated, the script will be executed, instead of compiling and running
>> the Csound files.
>>
>> Dynamically loading Python in this way did not used to be possible on
>> Windows before Python 2.4. because the Python functions did not used to
>> be exported in the Python DLL, but they are now. This opens a lot of
>> things up and makes it possible for the program to run if Python is not
>> present.
>>
>> As Steven Yi suggested, this may possible with other scripting languages
>> as well.
>>
>> Other suggestions follow.
>>
>> I think it would be desirable to add a button that links to the Csound
>> HTML help with a configurable path. FLTK has some sort of HTML browser,
>> though I'm not sure it's good enough for this.
>>
>> I think "Seek" or "Goto" is a better term than "Apply" for the score
>> offset, which is a nice feature.
>>
>> Putting dummy widgets in so as not to break widget orcs is a good idea.
>>
>> Did you look at John Ramsdell's flCsound? He had a feature of placing
>> FLTK graphs onto separate tabs that would be nice to have.
>>
>> Anyway, let me know what you think. I am not going to make any more
>> changes to CsoundVST for the time being.
>>
>> Regards,
>> Mike
>>
>> ----- Original Message ----- From: "Istvan Varga" 
>> To: 
>> Sent: Thursday, April 27, 2006 6:25 PM
>> Subject: Re: [Csnd] Csound 5 GUI frontends
>>
>>
>>> On Friday 28 April 2006 00:03, jpff@codemist.co.uk wrote:
>>>
>>>> So again my small free time is wasted.  Time to stop and go back to
>>>> writing music.
>>>
>>> Well, I mainly created this frontend to learn more about using FLTK
>>> and fluid, and also in response to recent criticism about Csound 5
>>> being "command line only". It remains to be seen if anyone actually
>>> finds it useful in practice, and if not, I will probably remove it
>>> from the CVS.
>>> -- 
>>> Send bugs reports to this list.
>>> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> Using Tomcat but need to do more? Need to support web services, security?
>> Get stuff done quickly with pre-integrated technology to make your job
>> easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache 
>> Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job 
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 




-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I agree that a situation where a Csound installer includes a plethora of
optional front-ends would be undesirable, i.e. I am advocating for case
two rather than case one.

If a "standard" front-end is to be included in the installer, I think it
would be helpful to make it an optional component of the installation.
This would clarify to all, I think - from the glorious moment that they
take their first plunge into Csound - that the language is one thing
[universal, required, shared] and its various front ends are another
thing altogether [specific, optional, personal].

Yours truly,
David

Michael Gogins wrote:
> There are two models here:
> 
> One, distribute a front end or front ends with the Csound installers.
> 
> Two, people distribute their own front ends from their own Web sites and
> with their own installers, built with the Csound API.
> 
> In case one, I don't see an advantage to having many front ends in one
> installer. In this case I do think there should be a "standard" just as
> I think there should be a standard Csound 5. I think this front end
> should be fairly simple, at least to start with.
> 
> In case two, the more, the merrier. This is one of the reasons I wanted
> there to be an API in the first place. And, I don't have to spend my
> time maintaining these front ends, and people can create the features
> THEY need and want. Over time, the various front end features that
> people like can be incorporated in the "standard" or, conversely, if an
> independent front end proves wildly popular it can simply be adopted as
> the standard, replacing the earlier one.
> 
> Regards,
> Mike
> 
> 
> ----- Original Message ----- From: "David Ogborn"
> 
> To: 
> Sent: Thursday, April 27, 2006 9:23 PM
> Subject: Re: [Cs-dev] Re: [Csnd] Csound 5 GUI frontends
> 
> 
>> Hello Michael, John and csound-devel list,
>>
>> I think that the fact that Csound 5 does not come with any particular
>> front-end, far from representing a liability is in fact an advantage.
>> It encourages the independent development of multiple "front-ends" to
>> reflect the great diversity of work processes employed by a great
>> diversity of electronic sound artists.
>>
>> I wonder what the community would gain by a certain front-end being
>> declared as the "standard" front-end.  Why not distribute all front-ends
>> as separate programs with Csound 5 as their major/only prerequisite?
>>
>> Yours truly,
>> David
>>
>> Michael Gogins wrote:
>>> I've played with your frontend, and looked a little bit at the sources.
>>>
>>> Basically, I like what you have done.  I like the transport controls and
>>> time counter, I think this is very useful, not least because its
>>> function will be obvious to musicians who are not programmers. I also
>>> like the fields for adding soundfile ID tags.
>>>
>>> I suggest that we combine CsoundVST and your GUI to make a standard
>>> frontend for Csound 5. I think this can be done in a way that would
>>> please both those who do not wish to install Python and those who do,
>>> reduce duplication of effort, and make Csound 5 more maintainable.
>>>
>>> First, allow me to point out some minor problems, then I will make some
>>> suggestions.
>>>
>>> The first problem is that there is a black console window, then there is
>>> a second console window (with a white background) for Csound messages.
>>> The first window can be omitted with the right linker flag, I think.
>>> Probably, you have just left this in for debugging purposes.
>>>
>>> The second problem is that configuration dialog has no "close" button
>>> (though Alt-F4 does close it), and it's a modal dialog so when it's
>>> open, you can't run Csound. This is obviously easy to fix in FLTK.
>>>
>>> I think it might be a problem that you construct the Csound command line
>>> entirely from dialogs. Perhaps there should also be a text field for
>>> additional flags by hand?
>>>
>>> Now for my suggestions.
>>>
>>> The main suggestion is to allow, but not require, the frontend to use
>>> Python.  This can be done by (a) calling Python via dl_open and dl_sym
>>> (or the Windows equivalents) instead of linking statically, and (b) by
>>> changing the Python Csound API to permit plugging an existing instance
>>> of Csound into Python (CsoundVST does it the other way round, creates
>>> Csound in Python then extracts it for the GUI). This would enable Csound
>>> operated via Python to print messages to the console, operate the time
>>> counter, etc. In other words, if the frontend can load the Python
>>> library, it will unhide a script editing button and plug its already
>>> created instance of Csound into Python. If the script field is
>>> populated, the script will be executed, instead of compiling and running
>>> the Csound files.
>>>
>>> Dynamically loading Python in this way did not used to be possible on
>>> Windows before Python 2.4. because the Python functions did not used to
>>> be exported in the Python DLL, but they are now. This opens a lot of
>>> things up and makes it possible for the program to run if Python is not
>>> present.
>>>
>>> As Steven Yi suggested, this may possible with other scripting languages
>>> as well.
>>>
>>> Other suggestions follow.
>>>
>>> I think it would be desirable to add a button that links to the Csound
>>> HTML help with a configurable path. FLTK has some sort of HTML browser,
>>> though I'm not sure it's good enough for this.
>>>
>>> I think "Seek" or "Goto" is a better term than "Apply" for the score
>>> offset, which is a nice feature.
>>>
>>> Putting dummy widgets in so as not to break widget orcs is a good idea.
>>>
>>> Did you look at John Ramsdell's flCsound? He had a feature of placing
>>> FLTK graphs onto separate tabs that would be nice to have.
>>>
>>> Anyway, let me know what you think. I am not going to make any more
>>> changes to CsoundVST for the time being.
>>>
>>> Regards,
>>> Mike
>>>
>>> ----- Original Message ----- From: "Istvan Varga"
>>> 
>>> To: 
>>> Sent: Thursday, April 27, 2006 6:25 PM
>>> Subject: Re: [Csnd] Csound 5 GUI frontends
>>>
>>>
>>>> On Friday 28 April 2006 00:03, jpff@codemist.co.uk wrote:
>>>>
>>>>> So again my small free time is wasted.  Time to stop and go back to
>>>>> writing music.
>>>>
>>>> Well, I mainly created this frontend to learn more about using FLTK
>>>> and fluid, and also in response to recent criticism about Csound 5
>>>> being "command line only". It remains to be seen if anyone actually
>>>> finds it useful in practice, and if not, I will probably remove it
>>>> from the CVS.
>>>> -- 
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>>>>
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> Using Tomcat but need to do more? Need to support web services,
>>> security?
>>> Get stuff done quickly with pre-integrated technology to make your job
>>> easier
>>> Download IBM WebSphere Application Server v.1.0.1 based on Apache
>>> Geronimo
>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> -------------------------------------------------------
>> Using Tomcat but need to do more? Need to support web services, security?
>> Get stuff done quickly with pre-integrated technology to make your job
>> easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache
>> Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
> 
> 
> 
> 
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net