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

Date	2011-04-05 17:05
From	"Art Hunkins"
Subject	Re: [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

Date	2011-04-05 17:14
From	Steven Yi
Subject	Re: [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