« Return to Thread: sc crossplatform future (was re: sc3 with emacs on windows?)
Re: sc crossplatform future (was re: sc3 with emacs on windows?)
by altern
::
Rate this Message:
hi
two more cents on this...
i am probably not the best to talk about this because i dont work so
much with sclang but maybe my point of view could be interesting for the
community?.
I work with several tools including PD and Python. I always try to
develop crossplatform code as much as possible,. So I value languages,
GUI toolkits and also IDEs which are crosplatform and consistent.
My relation with supercollider is very problematic because I have to use
use three different IDEs, one for in each platform (gEdit,
supercollider, psycollider),. Each of them has its own peculiarities and
small issues. Same goes for GUI, even SwingOSC, which is quite amazing,
is still buggy.
All this is of course because being supercollider native from OSX most
users are on OSX and therefore the usage and development of SwingOSC is
not as intense as we all would dream. Having one single GUI solution for
all platforms would boost and easy enormously the development of more
complex GUIs in supercollider.
I know by first hand that developing crossplatform code is a pain in the
ass but in my opinion it is worth. If we compare the experience of using
for example PD to that of using supercollider in different platforms
there is yet a huge gap to fill despite of latest versions advances. PD
is almost 100% consistent. (I am not trying to say this is better than
that, just pointing that PD works almost the same in Linux/Win/OSX)
In my opinion a crossplatform and stable GUI and IDE would help
spreading the usage of supercollider.
enrike
thor(e)k dio:
> Hi all.
>
> Interesting discussion. Here are my 2cents on the GUI issue:
>
> We spent the last weekend on porting ixiQuarks to SwingOSC.
> I can tell you it was no fun. When working with complex GUIs and GUI
> updates,
> an OSC GUI server is not as desirable as a GUI toolkit inbuilt with
> the language.
>
> And on our machines (Powerbook 1000 Hz and IBM 1500 Hz (I think)) Java
> was quite slow and did not give the feeling of a solid, well
> functioning software.
> (There were lots of things that were not translatable from Cocoa to
> SwingOSC.
> I can provide a list if anyone is interested.)
>
> I think Qt is a much more appropriate choice. It's free as long as it
> is GPL and
> properly cross platform.
>
> There is also Juce: http://www.rawmaterialsoftware.com/juce/
> (looks like cycling coded Max5 with it???)
>
> So my view is this:
> a) ideally the GUI should be part of the language (and not a GUI OSC
> server)
> b) It should not be Java or any other slow language.
>
> I would hope that in future versions of SC, the GUI could draw real-
> time time domain
> and frequency domain views and that is not easy to do when passing
> OSC data around like we're doing now. (Spectral view is not really
> possible
> although Scott made a cool implementation in QC. And the wave view
> (scope)
> is much worse than it was in SC2).
>
> This is hard to implement in SC3 (Unless someone really makes an
> effort to
> incorporate Qt with the sourcecode - not as a server).
>
> Perhaps SC4 will give us a good solution for GUIs?
>
> thor
>
> PS. the above is not meant to devalue in any way Sciss's SwingOSC server
> which is fantastic temporary solution and very good work indeed.
> (where would we be without it???)
>
>
>
>
>
>
> On 2 May 2008, at 10:43, Dan Stowell wrote:
>
>> 2008/5/2 James Harkins <jamshark70@...>:
>>> On Apr 30, 2008, at 5:13 AM, John Glover wrote:
>>>
>>>> Personally I think it would be a good idea to create a sclang app on
>>>> windows so things are closer to the other platforms. The GUI app
>>>> could
>>>> then be written in something cross-platform such as QT, WxWidgets or
>>>> even Java.
>>> I remember we had this discussion once upon a time, but nobody
>>> could agree
>>> which toolkit to use. While the fur was flying, sciss got started on
>>> swingosc and ended up doing such a fantastic job on it that it
>>> basically
>>> stopped the conversation.
>>>
>>> I don't have any strong objection to reimplementing the cocoa
>>> widgets using
>>> some other toolkit, provided the sc classes retain as much
>>> compatibility as
>>> possible with existing user code.
>> I agree that if the "main" or "default" sclang editor was a
>> cross-platform one that would be great, and would be a good way to
>> make the best use of limited developer time. I can see that trying to
>> get community agreement on a toolkit (or whatever) would be futile -
>> would we have agreed on a Java GUI server? I doubt it, instead sciss
>> just made it and It Was Good.
>>
>> Similarly the future of crossplatform sclang editor is going to be
>> determined by where the developer effort goes and where the
>> user-takeup goes. At the moment we have plenty of interesting
>> candidates, and I feel like the evolutionary race is just beginning...
>>
>> Dan
>> _______________________________________________
>> sc-users mailing list
>> sc-users@...
>> http://lists.create.ucsb.edu/mailman/listinfo/sc-users
>
> _______________________________________________
> sc-users mailing list
> sc-users@...
> http://lists.create.ucsb.edu/mailman/listinfo/sc-users
>
_______________________________________________
sc-users mailing list
sc-users@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-users
two more cents on this...
i am probably not the best to talk about this because i dont work so
much with sclang but maybe my point of view could be interesting for the
community?.
I work with several tools including PD and Python. I always try to
develop crossplatform code as much as possible,. So I value languages,
GUI toolkits and also IDEs which are crosplatform and consistent.
My relation with supercollider is very problematic because I have to use
use three different IDEs, one for in each platform (gEdit,
supercollider, psycollider),. Each of them has its own peculiarities and
small issues. Same goes for GUI, even SwingOSC, which is quite amazing,
is still buggy.
All this is of course because being supercollider native from OSX most
users are on OSX and therefore the usage and development of SwingOSC is
not as intense as we all would dream. Having one single GUI solution for
all platforms would boost and easy enormously the development of more
complex GUIs in supercollider.
I know by first hand that developing crossplatform code is a pain in the
ass but in my opinion it is worth. If we compare the experience of using
for example PD to that of using supercollider in different platforms
there is yet a huge gap to fill despite of latest versions advances. PD
is almost 100% consistent. (I am not trying to say this is better than
that, just pointing that PD works almost the same in Linux/Win/OSX)
In my opinion a crossplatform and stable GUI and IDE would help
spreading the usage of supercollider.
enrike
thor(e)k dio:
> Hi all.
>
> Interesting discussion. Here are my 2cents on the GUI issue:
>
> We spent the last weekend on porting ixiQuarks to SwingOSC.
> I can tell you it was no fun. When working with complex GUIs and GUI
> updates,
> an OSC GUI server is not as desirable as a GUI toolkit inbuilt with
> the language.
>
> And on our machines (Powerbook 1000 Hz and IBM 1500 Hz (I think)) Java
> was quite slow and did not give the feeling of a solid, well
> functioning software.
> (There were lots of things that were not translatable from Cocoa to
> SwingOSC.
> I can provide a list if anyone is interested.)
>
> I think Qt is a much more appropriate choice. It's free as long as it
> is GPL and
> properly cross platform.
>
> There is also Juce: http://www.rawmaterialsoftware.com/juce/
> (looks like cycling coded Max5 with it???)
>
> So my view is this:
> a) ideally the GUI should be part of the language (and not a GUI OSC
> server)
> b) It should not be Java or any other slow language.
>
> I would hope that in future versions of SC, the GUI could draw real-
> time time domain
> and frequency domain views and that is not easy to do when passing
> OSC data around like we're doing now. (Spectral view is not really
> possible
> although Scott made a cool implementation in QC. And the wave view
> (scope)
> is much worse than it was in SC2).
>
> This is hard to implement in SC3 (Unless someone really makes an
> effort to
> incorporate Qt with the sourcecode - not as a server).
>
> Perhaps SC4 will give us a good solution for GUIs?
>
> thor
>
> PS. the above is not meant to devalue in any way Sciss's SwingOSC server
> which is fantastic temporary solution and very good work indeed.
> (where would we be without it???)
>
>
>
>
>
>
> On 2 May 2008, at 10:43, Dan Stowell wrote:
>
>> 2008/5/2 James Harkins <jamshark70@...>:
>>> On Apr 30, 2008, at 5:13 AM, John Glover wrote:
>>>
>>>> Personally I think it would be a good idea to create a sclang app on
>>>> windows so things are closer to the other platforms. The GUI app
>>>> could
>>>> then be written in something cross-platform such as QT, WxWidgets or
>>>> even Java.
>>> I remember we had this discussion once upon a time, but nobody
>>> could agree
>>> which toolkit to use. While the fur was flying, sciss got started on
>>> swingosc and ended up doing such a fantastic job on it that it
>>> basically
>>> stopped the conversation.
>>>
>>> I don't have any strong objection to reimplementing the cocoa
>>> widgets using
>>> some other toolkit, provided the sc classes retain as much
>>> compatibility as
>>> possible with existing user code.
>> I agree that if the "main" or "default" sclang editor was a
>> cross-platform one that would be great, and would be a good way to
>> make the best use of limited developer time. I can see that trying to
>> get community agreement on a toolkit (or whatever) would be futile -
>> would we have agreed on a Java GUI server? I doubt it, instead sciss
>> just made it and It Was Good.
>>
>> Similarly the future of crossplatform sclang editor is going to be
>> determined by where the developer effort goes and where the
>> user-takeup goes. At the moment we have plenty of interesting
>> candidates, and I feel like the evolutionary race is just beginning...
>>
>> Dan
>> _______________________________________________
>> sc-users mailing list
>> sc-users@...
>> http://lists.create.ucsb.edu/mailman/listinfo/sc-users
>
> _______________________________________________
> sc-users mailing list
> sc-users@...
> http://lists.create.ucsb.edu/mailman/listinfo/sc-users
>
_______________________________________________
sc-users mailing list
sc-users@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-users
« Return to Thread: sc crossplatform future (was re: sc3 with emacs on windows?)
| Free Forum Powered by Nabble | Forum Help |