sc crossplatform future (was re: sc3 with emacs on windows?)

[Scott Wilson-8]

Hey Enrike,

>
> It is pretty clear that most supercollider users use mac and that
> historically supercollider has been mac centred. I think the community
> has to choose, either support all platforms or dont, with all
> consequences. Otherwise we will end up with a windows and linux  
> versions
> which are the "junior" version of the mac one and those users they  
> will
> be "forced" to either look for something else or jump into mac or be
> always slightly behind.
>
> It is just to easy to think when developing something "oh, anyway  
> there
> are just few windows users" thats an endless vicious circle. Like it  
> or
> not most computer users are on windows, and many musicians and
> programers too, specially in some areas of the world.

I don't think that anybody thinks that, and in fact since the last  
symposium there has been more effort then ever to keep developers on  
all platforms 'in the loop' on relevant issues, and to approach things  
with cross-platform issues in mind.

The real problem is that the windows and linux ports were started by a  
few people, and are still only maintained by a few people, who (like  
all the developers) basically do their work for free. More developers  
working on those ports would make a huge difference. That said I think  
the work of people like Marije and Chris is really deserving of  
praise. Things have come a long, long way on those platforms.  
Unfortunately they don't do SC development full time, and sometimes  
things lag. It's similar with SwingOSC really, as Sciss is not able to  
devote as much time to it as he used to.

S.
_______________________________________________
sc-users mailing list
sc-users@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-users

[thelych]

one little cent on this,

It is pretty clear that most supercollider users use mac and that
historically supercollider has been mac centred. I think the community
has to choose, either support all platforms or dont, with all
consequences.

i think most people, even the developper would like a cross platform version but it takes some time. 

People who are already in (ex: psycollider) are contantly improving it. 

You need always a first version before you can make a second one. 

With some patience i am sure things will be done. 

The supercollider community is not as big as the CSound one.

Otherwise we will end up with a windows and linux versions
which are the "junior" version of the mac one and those users they will
be "forced" to either look for something else or jump into mac or be
always slightly behind.

Why not start a Qt based development and get a "junior" version for windows/linux users ?

Florian Schmidt has a good starting point for a project. (http://tapas.affenbande.org/qcollider_screen2.png)

It is just to easy to think when developing something "oh, anyway there 
are just few windows users" thats an endless vicious circle. Like it or 
not most computer users are on windows, and many musicians and 
programers too, specially in some areas of the world.

(personal opinion) I agree with you. But i think it is also easy to point out all the current problems around Psycollider and Swing.

I agree here with Scott Wilson's point of view. If Linux developpers can start on something with Qt (or Juce or FLTK), it does not prevent windows developpers to help on psycollider. And / Or some people to help on Swing improvements / modifications.

The mac client is stable, effective, it allows mac users to benefit from cocoa additions (ex: QC view, cocoa bridge...ect...). 

I guess windows developpers may be benefit from .NET platform or DirectX specific stuff.

It is also possible to conform to a specific interface in the sc language side but have different implementations on the source side. I don't see any problems with that if it works well.

Cross platform development is really good for maintainability but since there is already different specific projects why not helping for improvements on those. It is as challenging as creating a new universal-scclient project and you can benefit from the experience of the current developpers.

Audacity is also really slow too.... And you're right, I almost suggested
Juce a few months back because the API's are incredibly easy to work with
and well organized, but it's way to slow to be useful with SC.

May be write a cross platform API in assembler... ;-) 

Or may be create a Fortran based one. :-(.... just kidding

Performance is not the point at this point. And it is not true anyway. (If it is good apparently for David Zicarelli, i do not know why it won't for supercollider)

Java can also be fast. So considering a Java based client (thx SwingOSC) is possible. You are lucky. someone made it.

Easy to say something is slower than...  If i had more knowledge of Java, and much more time. i would help sciss.

one very small cent added,

charles

_______________________________________________
sc-users mailing list
sc-users@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-users

[nescivi]

Hiho,

On Friday 02 May 2008 16:23:13 thor wrote:
> - Cross platform HID, Wacom, etc. support.

I don't think these are part of a GUI toolkit. The fact that Wacom is on OSX
related to a GUI object is a bit weird, imo. On Linux a wacom tablet is
accessible much more easily through LID (and thus through GeneralHID).

They do need work still though, and in some free time over the next 6 months
or so, I will take the time to see how for example Pd or Chuck is dealing
with these to come up with a solution.

For the Wii however there does not seem to be a full featured cross platform
library yet...

sincerely,
Marije
_______________________________________________
sc-users mailing list
sc-users@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-users

[nescivi]

Hiho,

On Saturday 03 May 2008 04:53:10 Scott Wilson wrote:
> I don't think that anybody thinks that, and in fact since the last
> symposium there has been more effort then ever to keep developers on
> all platforms 'in the loop' on relevant issues, and to approach things
> with cross-platform issues in mind.

I got a nice comment from a student of the SC-crash course I taught in
Montreal that he found it very encouraging that I was teaching it using a
Linux computer, instead of a Mac.
So maybe that's a key :)
I also think that for people teaching SC to be at least aware of how some
things work on different platforms is a key issue to not let students on
other platforms in the dark and on their own to figure out the platform
specific things.

I'm glad that by now some more people are on board, who help out with some
Linux issues, as well as Windows.

I don't think that it is possible to steer the cross platform development to a
common UI, nor that that is necessary.
Underlying things to make code work the same is much more important, I think,
e.g. for I/O things.
And for crossplatform necessities like HTML basic format, should be based on a
crossplatform basis, as Andrea mentioned.

sincerely,
Marije
_______________________________________________
sc-users mailing list
sc-users@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-users

[Eric Lyon]

As a casual user of SC, I completely agree with Marije about the UI. After spending some time building SC UIs, I concluded that it was just too much of a pain to code up the location and size of every UI element, compared to the instant gratification of drag-n-drop graphical layout design. So now if I need a front end to some SC code, I wire up the UI in Max and udpsend the control information to SC. I reckon Pd would work just as well as Max for this purpose, though it might not be as pretty :)

Cheers,

Eric

On Sat, May 3, 2008 at 10:32 AM, nescivi <nescivi@...> wrote:

Hiho,

I don't think that it is possible to steer the cross platform development to a
common UI, nor that that is necessary.
Underlying things to make code work the same is much more important, I think,
e.g. for I/O things.
And for crossplatform necessities like HTML basic format, should be based on a
crossplatform basis, as Andrea mentioned.

sincerely,
Marije

_______________________________________________
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

[Scott Wilson-8]

Hey Eric,

FWIW, you do know that the GUI builder under the UI menu pretty much works now?

S.

On 3 May 2008, at 12:25, Eric Lyon wrote:

As a casual user of SC, I completely agree with Marije about the UI. After spending some time building SC UIs, I concluded that it was just too much of a pain to code up the location and size of every UI element, compared to the instant gratification of drag-n-drop graphical layout design. So now if I need a front end to some SC code, I wire up the UI in Max and udpsend the control information to SC. I reckon Pd would work just as well as Max for this purpose, though it might not be as pretty :)

Cheers,

Eric

On Sat, May 3, 2008 at 10:32 AM, nescivi <nescivi@...> wrote:

Hiho,

I don't think that it is possible to steer the cross platform development to a
common UI, nor that that is necessary.
Underlying things to make code work the same is much more important, I think,
e.g. for I/O things.
And for crossplatform necessities like HTML basic format, should be based on a
crossplatform basis, as Andrea mentioned.

sincerely,
Marije

_______________________________________________
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

[Eric Lyon]

Hi Scott,

That looks pretty cool! I can see how it would be helpful. Does it work similarly on Windows and Linux? Also, it seems like a lot of cut-n-pasting to bring all the UI code together. I'm pretty happy with just one line of code to field each control stream, and then doing everything else in Max:

({
    var frak = Bus.control(s,1);
    var cut = Bus.control(s,1);
    frak.set(400);
    cut.set(3000);
    OSCresponderNode(nil, '/sawfreq', { |t,r,m| frak.set(m[1]) }).add;
    OSCresponderNode(nil, '/cutoff', { |t,r,m| cut.set(m[1]) }).add;
    LPF.ar(Saw.ar(In.kr(frak)), In.kr(cut), 0.2)
}.play)

Cheers,

Eric

_______________________________________________
sc-users mailing list
sc-users@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-users

[Eric Lyon]

Sorry, I should have showed the complete patch:

_______________________________________________
sc-users mailing list
sc-users@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-users

[Arie van Schutterhoef]

>if I need a front end to some SC code, I wire up the UI in Max and udpsend
>the control >information to SC.
-Probably a lot of people are doing that (at least we do...)!
 SC's quality as far as I am concerned lies in its wonderfull structural
language and audio-engine.

>I reckon Pd would work just as well as Max for this purpose, though it
>might not be as >pretty :)
-You can either use Jitter or GEM to win that beauty-contest, if you want...

AvS

......................................................................
......................................................................
     ` *===========================================================+++
     ` |arsche.net sound-image-word http://www.arsche.net/index.html |
       *===========================================================+++
     ` |Schreck Ensemble/Assembly - live electro-acoustic music-     |
     ` |             http://www.schreck.nl/index.html                |
     ` *===========================================================+++
     ` |S T R A T I F I E R - a multi-dimensional controller-        |
     ` |                  http://www.stratifier.nl/index.html        |
     ` *============================================================++
    . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
......................................................................


_______________________________________________
sc-users mailing list
sc-users@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-users

[Scott Wilson-8]

On 3 May 2008, at 13:51, Eric Lyon wrote:

> Hi Scott,
>
> That looks pretty cool! I can see how it would be helpful. Does it  
> work similarly on Windows and Linux?

Hmm... It doesn't use GUI, so it doesn't look like it at the moment.  
May be possible though to modify it to do so.

> Also, it seems like a lot of cut-n-pasting to bring all the UI code  
> together. I'm pretty happy with just one line of code to field each  
> control stream, and then doing everything else in Max:

It's the trade-off I suppose of a text based language. It's possible  
to do things with dynamic GUI generation and auto layout in SC which  
would be difficult or impossible in Max (at least without using  
Javascript), but in Max the code for a slider is, well, a slider.

S.
_______________________________________________
sc-users mailing list
sc-users@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-users

[Scott Wilson-8]

Hmm. I imagine it's not much less typing though is it?

On 3 May 2008, at 14:01, Eric Lyon wrote:

> Sorry, I should have showed the complete patch:
>
>
>
> _______________________________________________
> 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

[Arie van Schutterhoef]

>It's the trade-off I suppose of a text based language. It's possible
>to do things with dynamic GUI generation and auto layout in SC which
>would be difficult or impossible in Max (at least without using
>Javascript), but in Max the code for a slider is, well, a slider.
-It is just a matter of using different tools for different jobs.

I have not come across something that is the solution to all problems. But
that might not be a reason attempting to create one (...another
software-package...).

AvS

......................................................................
......................................................................
     ` *===========================================================+++
     ` |arsche.net sound-image-word http://www.arsche.net/index.html |
       *===========================================================+++
     ` |Schreck Ensemble/Assembly - live electro-acoustic music-     |
     ` |             http://www.schreck.nl/index.html                |
     ` *===========================================================+++
     ` |S T R A T I F I E R - a multi-dimensional controller-        |
     ` |                  http://www.stratifier.nl/index.html        |
     ` *============================================================++
    . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
......................................................................


_______________________________________________
sc-users mailing list
sc-users@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-users

[Eric Lyon]

> Also, it seems like a lot of cut-n-pasting to bring all the UI code
> together. I'm pretty happy with just one line of code to field each
> control stream, and then doing everything else in Max:

It's the trade-off I suppose of a text based language. It's possible
to do things with dynamic GUI generation and auto layout in SC which
would be difficult or impossible in Max (at least without using
Javascript),

Fortunately, with Javascript, all of the above is a piece of cake in Max :) That said, if I needed a scripted GUI to control SC, I'd probably write it in SC. More direct.
 

but in Max the code for a slider is, well, a slider.

Actually, now that Max 5 has gone attribute-crazy, it's gotten a bit more open.

Cheers,

Eric

_______________________________________________
sc-users mailing list
sc-users@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-users

[nescivi]

Hiho,

On Saturday 03 May 2008 07:25:19 Eric Lyon wrote:
> As a casual user of SC, I completely agree with Marije about the UI. After
> spending some time building SC UIs, I concluded that it was just too much
> of a pain to code up the location and size of every UI element, compared to
> the instant gratification of drag-n-drop graphical layout design. So now if
> I need a front end to some SC code, I wire up the UI in Max and udpsend the
> control information to SC. I reckon Pd would work just as well as Max for
> this purpose, though it might not be as pretty :)

I actually meant more the editor... since many people prefer different
editors, even within one platform, I don't see this actually merging to one
standard across platforms. Since we're in a do-ocracy, only if someone comes
up with something really, really brilliant, implements most of it, and
impresses enough other devs to join in, it would happen... but you can't
steer this.

GUI elements are of course a concern, but for me personally only limited...
since I either have graphicless interfaces for sound installations, or very,
very simple performance monitoring interfaces for performances...

hence my focus more on I/O systems, since I tend to need those to work cross
platform, because of the computers one gets offered to let a sound
installation run on...

sincerely,
Marije

>
> Cheers,
>
> Eric
>
> On Sat, May 3, 2008 at 10:32 AM, nescivi <nescivi@...> wrote:
> > Hiho,
> >
> > I don't think that it is possible to steer the cross platform development
> > to a
> > common UI, nor that that is necessary.
> > Underlying things to make code work the same is much more important, I
> > think,
> > e.g. for I/O things.
> > And for crossplatform necessities like HTML basic format, should be based
> > on a
> > crossplatform basis, as Andrea mentioned.
> >
> > sincerely,
> > Marije
> > _______________________________________________
> > 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

[Scott Wilson-8]

On 3 May 2008, at 14:21, Eric Lyon wrote:

> Also, it seems like a lot of cut-n-pasting to bring all the UI code
> together. I'm pretty happy with just one line of code to field each
> control stream, and then doing everything else in Max:

It's the trade-off I suppose of a text based language. It's possible
to do things with dynamic GUI generation and auto layout in SC which
would be difficult or impossible in Max (at least without using
Javascript),

Fortunately, with Javascript, all of the above is a piece of cake in Max :) That said, if I needed a scripted GUI to control SC, I'd probably write it in SC. More direct.

Yeah, I like SC as a language much more than JS anyway.

And the dynamic audio graph in SC is something I'm pretty much addicted to.

 

but in Max the code for a slider is, well, a slider.

Actually, now that Max 5 has gone attribute-crazy, it's gotten a bit more open.

It's been very interesting watching Max take on more characteristics of text based languages as it expands (and sells upgrades ;-), like namespaces and attributes (i.e. instance variables). Some max patches have so much typing in them these days that the 'graphic' element seems a little incidental.

The new inspector looks quite nice though.

S.

_______________________________________________
sc-users mailing list
sc-users@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-users

[Eric Lyon]

And the dynamic audio graph in SC is something I'm pretty much addicted to.

That's one of my favorite SC things. The way the Max DSP chain is built precludes live coding in Max unless you really like clicks.

Cheers,

Eric

_______________________________________________
sc-users mailing list
sc-users@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-users

[James Harkins-2]

BTW, decorators in SC help a lot with building GUIs. You still have to code sizes but the decorator positions the views automatically according to left-to-right or top-to-bottom order.

Once I started using FlowView instead of GUI.window, I never looked back...

hjh

On May 3, 2008, at 7:25 AM, Eric Lyon wrote:

As a casual user of SC, I completely agree with Marije about the UI. After spending some time building SC UIs, I concluded that it was just too much of a pain to code up the location and size of every UI element, compared to the instant gratification of drag-n-drop graphical layout design. So now if I need a front end to some SC code, I wire up the UI in Max and udpsend the control information to SC. I reckon Pd would work just as well as Max for this purpose, though it might not be as pretty :)

: H. James Harkins

: jamshark70@...

: http://www.dewdrop-world.net

.::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:

"Come said the Muse,

Sing me a song no poet has yet chanted,

Sing me the universal."  --