Provide a concise but complete set of requirements for a "simple GUI" and I 
will see if I think it is easy enough to adapt or make one.

You could draw screen shots with buttons and menus if that is clearer than a 
text description.

Regards,
Mike

----- Original Message ----- 
From: "Art Hunkins" 
To: "Developer discussions" 
Sent: Thursday, January 04, 2007 5:20 PM
Subject: Re: [Cs-dev] Building on x86_64


> Although I'm very happy with the Lettuce environment, I feel strongly that
> some alternate, *simple* Windows front end should be available and
> maintained. Are there other candidates beside Csound5GUI and Winsound?
>
> IMHO, both of the above are worthy software; both (as noted) have a couple
> of weak spots. Surely, an interested developer could eliminate the latter.
>
> *Perhaps* the fact that Istvan is no longer a developer (at least here)
> rules out Csound5GUI - though I've yet to be completely convinced of this.
> Let me simply repeat that it is my fond hope that *at least one* of these
> fine programs will thrive and grow - appropriately nourished.
>
> Art Hunkins
>
> ----- Original Message ----- 
> From: "jpff" 
> To: 
> Sent: Thursday, January 04, 2007 4:33 PM
> Subject: [Cs-dev] Building on x86_64
>
>
>> I finally managed to build most stuff on the machine; I had to
>> compiler swig 1.3.31 from source and install and that seemed to fix a
>> number of issues.  If we really need the latest cutting edge SWIG it
>> really ought to be tested for.
>>
>> I still have the lack of declaration of numBuffersInput in
>> frontends/fltk_gui but I suspect that is a side effect of fltk1.1.7
>> not building on x86_64; again that needs to be tested for if we require
>> the latest version.
>>
>> Yes I know I am being grumpy(*) but i have wasted hours on this.
>>
>> My questions about 0.0/0.0 was really curiosity.  I could not find a
>> definition of the functions P() etc and in C I would expect an
>> interrupt.
>>
>> Next issue; do we really need an opcode to call out?  (I dislike the
>> name shell as it comes from one subculture and its meaning is not
>> obvious; at least system is a C function call and it does wait btw).
>>
>> What is the future of the various GUI systems?  I stopped developing
>> winsound as it was clearly being rubbished.  So who is maintaining
>> fltk_gui?
>>
>> ==John ffitch
>> (*) and I am not feeling well today
>>
>> -------------------------------------------------------------------------
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
>> opinions on IT & business topics through brief surveys - and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share 
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel 


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Permit me to add some thoughts on this, though not specifically  
related to x86_64.

* IMO Csound and it's operation under various (eg parallel,  
heterogeneous) computing
  environments should be the principle focus of development.

* UI is related to the ways Csound is used in making (compositions,  
sonifications etc)
* HW platforms change and which particular platform one uses for a  
particular task is
  related to what one has at hand + which best suits the particular  
combination of tasks
  one is undertaking at a particular time. This changes, sometimes  
daily.

* GUI's take a _lot_ of time to develop

* Given that any combination is possible, and development time is of  
the essence,
  it stands to reason that better results would be achieved if the  
effort is focussed on
  fewer variations.

* Any UI above the commandline is use-related i.e it is a component  
of composition/
  performance/rendering. In realtime work one doesn't always have the  
luxury of going
  from score generation to rendering via disk. One needs to use pipes.

* A user might want to develop a collection of GUIs (windows,  
dialogs) for a specific task
  and control other things via the CLI. Locking everything 'under the  
hood' of a pre-defined
  and event-loop GUI is  like forcing users to convert their  
compositions to the score language.

* To me this suggests an approach in which GUI is part of the wrapper  
around a dynamic
library and it is better to spend one's time bettering wrappers for  
different languages
  (python, lisp, ruby, c++ etc etc) around csound as a dynamic  
library (or system calls or
  through named pipes) than trying to develop different GUIs on  
different platforms whilst
  trying to imagine what users might want.

* If wxWidgets is used, the same GUI code is usable on all platforms.  
[I've just done a
  compile of a large program of an Intel Mac of C++ code written on  
Ubuntu Linux. Untested
   by the author on any other platform, The GUI came up just like it  
was meant to. Beautiful!
  I've spent 100's of hours scratching around GUI tools and IMO  
wxWidgets runs rings
  around the rest.

* There are GUI tools for GUI design (such as Glade) which can for a  
large part open
  the design process to the user/developer community, much as UGEN  
design is.

* Focus can then be placed on improving/standardising the  
communication protocol
  between GUI/wrappers and CS proper. This probably means considered  
XML/OSC support.

* Where one puts things like the presynthesis f-table displays could  
be debated. I've been
used to seeing them since music 5, or at least C, and they remain a  
quick feedback,
  but they're not essential to the operation of csound.

My quickie 2c worth. Not meaning to tread on anyone's toes.... :-)

ciao, David

On 05/01/2007, at 10:52 AM, Michael Gogins wrote:

> Provide a concise but complete set of requirements for a "simple  
> GUI" and I
> will see if I think it is easy enough to adapt or make one.
>
> You could draw screen shots with buttons and menus if that is  
> clearer than a
> text description.
>
> Regards,
> Mike
>
> ----- Original Message -----
> From: "Art Hunkins" 
> To: "Developer discussions" 
> Sent: Thursday, January 04, 2007 5:20 PM
> Subject: Re: [Cs-dev] Building on x86_64
>
>
>> Although I'm very happy with the Lettuce environment, I feel  
>> strongly that
>> some alternate, *simple* Windows front end should be available and
>> maintained. Are there other candidates beside Csound5GUI and  
>> Winsound?
>>
>> IMHO, both of the above are worthy software; both (as noted) have  
>> a couple
>> of weak spots. Surely, an interested developer could eliminate the  
>> latter.
>>
>> *Perhaps* the fact that Istvan is no longer a developer (at least  
>> here)
>> rules out Csound5GUI - though I've yet to be completely convinced  
>> of this.
>> Let me simply repeat that it is my fond hope that *at least one*  
>> of these
>> fine programs will thrive and grow - appropriately nourished.
>>
>> Art Hunkins
>>
>> ----- Original Message -----
>> From: "jpff" 
>> To: 
>> Sent: Thursday, January 04, 2007 4:33 PM
>> Subject: [Cs-dev] Building on x86_64
>>
>>
>>> I finally managed to build most stuff on the machine; I had to
>>> compiler swig 1.3.31 from source and install and that seemed to  
>>> fix a
>>> number of issues.  If we really need the latest cutting edge SWIG it
>>> really ought to be tested for.
>>>
>>> I still have the lack of declaration of numBuffersInput in
>>> frontends/fltk_gui but I suspect that is a side effect of fltk1.1.7
>>> not building on x86_64; again that needs to be tested for if we  
>>> require
>>> the latest version.
>>>
>>> Yes I know I am being grumpy(*) but i have wasted hours on this.
>>>
>>> My questions about 0.0/0.0 was really curiosity.  I could not find a
>>> definition of the functions P() etc and in C I would expect an
>>> interrupt.
>>>
>>> Next issue; do we really need an opcode to call out?  (I dislike the
>>> name shell as it comes from one subculture and its meaning is not
>>> obvious; at least system is a C function call and it does wait btw).
>>>
>>> What is the future of the various GUI systems?  I stopped developing
>>> winsound as it was clearly being rubbished.  So who is maintaining
>>> fltk_gui?
>>>
>>> ==John ffitch
>>> (*) and I am not feeling well today
>>>
>>> -------------------------------------------------------------------- 
>>> -----
>>> Take Surveys. Earn Cash. Influence the Future of IT
>>> Join SourceForge.net's Techsay panel and you'll get the chance to  
>>> share
>> your
>>> opinions on IT & business topics through brief surveys - and earn  
>>> cash
>>> http://www.techsay.com/default.php? 
>>> page=join.php&p=sourceforge&CID=DEVDEV
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> --------------------------------------------------------------------- 
>> ----
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to  
>> share
>> your
>> opinions on IT & business topics through brief surveys - and earn  
>> cash
>> http://www.techsay.com/default.php? 
>> page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

_______________________________________
experimental polymedia:	www.avatar.com.au
Sonic Communications Research Group,
University of Canberra:	 www.canberra.edu.au





-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net