Csound Csound-dev Csound-tekno Search About

Re: [Cs-dev] GUI PROPOSAL - was Re: A personal request fornext csound

Date2011-04-05 17:05
From"Art Hunkins"
SubjectRe: [Cs-dev] GUI PROPOSAL - was Re: A personal request fornext csound
I'm with Victor.

I like to distribute an ultra-light, 7-8 file version of Csound with my 
performance pieces.

Art Hunkins

----- Original Message ----- 
From: "Victor Lazzarini" 
To: "Developer discussions" 
Sent: Tuesday, April 05, 2011 9:01 AM
Subject: Re: [Cs-dev] GUI PROPOSAL - was Re: A personal request fornext 
csound


>I would prefer if we didn't. I think there is a case for a light-
> weight csound with just basic opcodes.
>
> Victor
>
> On 5 Apr 2011, at 13:57, Steven Yi wrote:
>
>> I vote +1 for folding in all opcodes that do not have external
>> dependencies or licensing issues back into libcsound. If there are
>> no objections, I'll be happy to do this.
>>
>> Sent from my iPhone
>>
>> On Apr 5, 2011, at 5:50 AM, Richard Dobson 
>> > > wrote:
>>
>>> On 05/04/2011 03:01, matt ingalls wrote:
>>>>> This is what I would have suggested. I have never considered that
>>>>> there
>>>>> should be widget opcodes as such in the orchestra - that is best
>>>>> kept
>>>>> separate. Going back to the old paradigm of separate score and
>>>>> orchestra
>>>>
>>>> in general i agree (remember Richard i was the first one to do
>>>> this w/
>>>> MacCsound and the invalue/outvalue opcodes!!!!!!!)
>>>>
>>>
>>> I never thought or suggested otherwise.
>>>
>>>> BUT i can see some cases where doing some dynamic
>>>> generation/manipulation from orc could be very powerful
>>>> (iterative allocation of widgets for example) --
>>>>
>>>> if you look at my proposal more closely, it supports both.
>>>>
>>>
>>> I would prefer "iterative request for widgets" or "for ports" - the
>>> issue is the spectre of two engines competing with each other for
>>> control of the widget-world.  To me the best model is to see Csound
>>> itself (given its new modular architecture) as a gui-less server (it
>>> could even be in a separate process space altogether, not an unusual
>>> model these days), communicating possibly over a fast serial channel
>>> with clients who both handle widget messages from the server, and add
>>> their own ad lib. I don't think Csound itself should be allocating
>>> anything GUI-related at all, other than data/message ports.
>>>
>>> Run Csound on a netbook or tablet, and legible GUI real-estate is
>>> at a
>>> premium. If the GUI engine cannot control how much is displayed, and
>>> how, we are in trouble. So a CSD file that insists on dynamically
>>> creating clouds of widgets will not be safe. The computing world is
>>> no
>>> longer a simple question of whether to have a 19" monitor or a 26"
>>> one;
>>> we now have 7" screens to consider (again). So things have to be
>>> able to
>>> scale in both directions. With small screens, GUI elements may need
>>> to
>>> be arranged over multiple pages; and I suspect that the Csound engine
>>> itself is not best placed to determine that. But it could reasonably
>>> give hints to the host as to how widgets should be collected
>>> together.
>>>
>>> ....
>>>>
>>>>
>>>> are CsWidgets an updated of  or ???
>>>>>
>>>
>>> I have no idea - maybe. That was Andres's name, and I was
>>> responding to
>>> his comments. It could be called "CsGUI" or anything; so long as it
>>> is
>>> clearly platform-agnostic.
>>>
>>>>
>>>>> (Csound on the iPad
>>>>> 2?)
>>>>
>>>> good luck with that...
>>>>
>>> Not anything I will try to do anytime soon. iOS does not allow
>>> third-party dlls in any form, so porting Csound as is is not
>>> something
>>> that can be done quickly. Ironically, the old monolithic (and floats)
>>> Csound 4 would be much easier to deal with. But with STK compiling
>>> as a
>>> static library for iOS out of the box, and even the PD engine
>>> apparently
>>> built and being used, one has to wonder whether the effort to
>>> de-modularize Csound for iOS would be worthwhile. Plus ca change,
>>> etc;
>>> the modern all-modular Csound complete with plugin opcodes has many
>>> virtues; but the old model has not lost its traction, and may yet
>>> find a
>>> new lease of life!
>>>
>>> Richard Dobson
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Xperia(TM) PLAY
>>> It's a major breakthrough. An authentic gaming
>>> smartphone on the nation's most reliable network.
>>> And it wants your games.
>>> http://p.sf.net/sfu/verizon-sfdev
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Xperia(TM) PLAY
>> It's a major breakthrough. An authentic gaming
>> smartphone on the nation's most reliable network.
>> And it wants your games.
>> http://p.sf.net/sfu/verizon-sfdev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> Dr Victor Lazzarini
> Senior Lecturer
> Dept. of Music
> NUI Maynooth Ireland
> tel.: +353 1 708 3545
> Victor dot Lazzarini AT nuim dot ie
>
>
>
>
> ------------------------------------------------------------------------------
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel 


------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Date2011-04-05 17:14
FromSteven Yi
SubjectRe: [Cs-dev] GUI PROPOSAL - was Re: A personal request fornext csound
As mentioned previously, this doesn't have to be an either/or option.

For non-embedded/mobile platforms, file size isn't an issue IMO,
especially with the size of csound that we're talking about. When you
can buy a terrabyte for $100, and download speeds are fast enough to
stream large mp3's, a meg or two isn't a factor IMO.

For embedded/mobile, where size is a concern and the hard requirement
of no dynamic loading of libraries, we need a solution.  Currently we
are fine for normal desktop, but for project embedding we have no
options. Having the ability to pack in opcode libs that have no
external dependencies here is a necessity if anyone is going to pursue
this.

On Tue, Apr 5, 2011 at 12:05 PM, Art Hunkins  wrote:
> I'm with Victor.
>
> I like to distribute an ultra-light, 7-8 file version of Csound with my
> performance pieces.
>
> Art Hunkins
>
> ----- Original Message -----
> From: "Victor Lazzarini" 
> To: "Developer discussions" 
> Sent: Tuesday, April 05, 2011 9:01 AM
> Subject: Re: [Cs-dev] GUI PROPOSAL - was Re: A personal request fornext
> csound
>
>
>>I would prefer if we didn't. I think there is a case for a light-
>> weight csound with just basic opcodes.
>>
>> Victor
>>
>> On 5 Apr 2011, at 13:57, Steven Yi wrote:
>>
>>> I vote +1 for folding in all opcodes that do not have external
>>> dependencies or licensing issues back into libcsound. If there are
>>> no objections, I'll be happy to do this.
>>>
>>> Sent from my iPhone
>>>
>>> On Apr 5, 2011, at 5:50 AM, Richard Dobson
>>> >> > wrote:
>>>
>>>> On 05/04/2011 03:01, matt ingalls wrote:
>>>>>> This is what I would have suggested. I have never considered that
>>>>>> there
>>>>>> should be widget opcodes as such in the orchestra - that is best
>>>>>> kept
>>>>>> separate. Going back to the old paradigm of separate score and
>>>>>> orchestra
>>>>>
>>>>> in general i agree (remember Richard i was the first one to do
>>>>> this w/
>>>>> MacCsound and the invalue/outvalue opcodes!!!!!!!)
>>>>>
>>>>
>>>> I never thought or suggested otherwise.
>>>>
>>>>> BUT i can see some cases where doing some dynamic
>>>>> generation/manipulation from orc could be very powerful
>>>>> (iterative allocation of widgets for example) --
>>>>>
>>>>> if you look at my proposal more closely, it supports both.
>>>>>
>>>>
>>>> I would prefer "iterative request for widgets" or "for ports" - the
>>>> issue is the spectre of two engines competing with each other for
>>>> control of the widget-world.  To me the best model is to see Csound
>>>> itself (given its new modular architecture) as a gui-less server (it
>>>> could even be in a separate process space altogether, not an unusual
>>>> model these days), communicating possibly over a fast serial channel
>>>> with clients who both handle widget messages from the server, and add
>>>> their own ad lib. I don't think Csound itself should be allocating
>>>> anything GUI-related at all, other than data/message ports.
>>>>
>>>> Run Csound on a netbook or tablet, and legible GUI real-estate is
>>>> at a
>>>> premium. If the GUI engine cannot control how much is displayed, and
>>>> how, we are in trouble. So a CSD file that insists on dynamically
>>>> creating clouds of widgets will not be safe. The computing world is
>>>> no
>>>> longer a simple question of whether to have a 19" monitor or a 26"
>>>> one;
>>>> we now have 7" screens to consider (again). So things have to be
>>>> able to
>>>> scale in both directions. With small screens, GUI elements may need
>>>> to
>>>> be arranged over multiple pages; and I suspect that the Csound engine
>>>> itself is not best placed to determine that. But it could reasonably
>>>> give hints to the host as to how widgets should be collected
>>>> together.
>>>>
>>>> ....
>>>>>
>>>>>
>>>>> are CsWidgets an updated of  or ???
>>>>>>
>>>>
>>>> I have no idea - maybe. That was Andres's name, and I was
>>>> responding to
>>>> his comments. It could be called "CsGUI" or anything; so long as it
>>>> is
>>>> clearly platform-agnostic.
>>>>
>>>>>
>>>>>> (Csound on the iPad
>>>>>> 2?)
>>>>>
>>>>> good luck with that...
>>>>>
>>>> Not anything I will try to do anytime soon. iOS does not allow
>>>> third-party dlls in any form, so porting Csound as is is not
>>>> something
>>>> that can be done quickly. Ironically, the old monolithic (and floats)
>>>> Csound 4 would be much easier to deal with. But with STK compiling
>>>> as a
>>>> static library for iOS out of the box, and even the PD engine
>>>> apparently
>>>> built and being used, one has to wonder whether the effort to
>>>> de-modularize Csound for iOS would be worthwhile. Plus ca change,
>>>> etc;
>>>> the modern all-modular Csound complete with plugin opcodes has many
>>>> virtues; but the old model has not lost its traction, and may yet
>>>> find a
>>>> new lease of life!
>>>>
>>>> Richard Dobson
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Xperia(TM) PLAY
>>>> It's a major breakthrough. An authentic gaming
>>>> smartphone on the nation's most reliable network.
>>>> And it wants your games.
>>>> http://p.sf.net/sfu/verizon-sfdev
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Xperia(TM) PLAY
>>> It's a major breakthrough. An authentic gaming
>>> smartphone on the nation's most reliable network.
>>> And it wants your games.
>>> http://p.sf.net/sfu/verizon-sfdev
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> Dr Victor Lazzarini
>> Senior Lecturer
>> Dept. of Music
>> NUI Maynooth Ireland
>> tel.: +353 1 708 3545
>> Victor dot Lazzarini AT nuim dot ie
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Xperia(TM) PLAY
>> It's a major breakthrough. An authentic gaming
>> smartphone on the nation's most reliable network.
>> And it wants your games.
>> http://p.sf.net/sfu/verizon-sfdev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net