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

[Dan Stowell]

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

[thor-2]

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

[nescivi]

Hiho,

On Friday 02 May 2008 06:17:44 thor wrote:

> 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).

Fast implementations for these, would require a shared memory with scsynth, I
believe, not with the lang.

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

[thor-2]

On 2 May 2008, at 11:35, nescivi wrote:

> Hiho,

Hiho.

>
> On Friday 02 May 2008 06:17:44 thor wrote:
>> 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).
>
> Fast implementations for these, would require a shared memory with  
> scsynth, I
> believe, not with the lang.

That's true, thus my hopes for SC4 : )

But my main point was regarding the difference of making GUIs with Cocoa
(which is part of SC lang) vs ANY GUI server, where OSC communication
between lang and GUI is not ideal.

thor

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

[nescivi]

On Friday 02 May 2008 06:41:44 thor wrote:
> > Fast implementations for these, would require a shared memory with
> > scsynth, I
> > believe, not with the lang.
>
> That's true, thus my hopes for SC4 : )
>
> But my main point was regarding the difference of making GUIs with Cocoa
> (which is part of SC lang) vs ANY GUI server, where OSC communication
> between lang and GUI is not ideal.

Thus my hopes for language plugins, which would make it easier to have class
extensions which call primitives, without these having to be an integrated
part of the sclang application per se... This would make it easier for people
to start writing these, without them having to be integrated with the
official source tree, while they are in an experimental state...

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

[altern]

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

[andrea valle-3]

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 understand your point. 

But because of my interests, I see the main problems not in GUI (I'm happy with SwingOSC) but in the Document class, which is extremely powerful on OSX, but, in fact, it is fundamentally an OSX class.

So you can't rely on Document to have cross-platform behavior. Which is a pity, because you can use it to specify different UI modes (e.g. key bindings).

More, Document is strongly related to help file system. Help files are generated by Cocoa HTML writer. Sources are awful and incredibly dirty.

E.g.:

<meta name="Generator" content="Cocoa HTML Writer">

<meta name="CocoaVersion" content="824.44">

<style type="text/css">

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 18.0px Helvetica}

p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px}

p.p3 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; color: #0000ff}

p.p4 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica}

p.p5 {margin: 0.0px 0.0px 0.0px 0.0px; font: 9.0px Monaco}

p.p6 {margin: 0.0px 0.0px 0.0px 0.0px; font: 9.0px Monaco; color: #982c23}

p.p7 {margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Helvetica}

p.p8 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Monaco; min-height: 16.0px}

p.p9 {margin: 0.0px 0.0px 0.0px 0.0px; font: 9.0px Monaco; min-height: 12.0px}

p.p10 {margin: 0.0px 0.0px 0.0px 0.0px; font: 9.0px Monaco; color: #982c23; min-height: 12.0px}

p.p11 {margin: 0.0px 0.0px 0.0px 0.0px; font: 9.0px Monaco; color: #0024a4}

p.p12 {margin: 0.0px 0.0px 0.0px 0.0px; font: 9.0px Monaco; color: #606060}

span.s1 {color: #000000}

span.s2 {color: #0000ff}

span.s3 {color: #0024a4}

span.s4 {color: #bf0000}

span.s5 {color: #0024e4}

span.s6 {color: #436b2e}

span.s7 {color: #606060}

span.Apple-tab-span {white-space:pre}

</style>

</head>

<body>

<p class="p1"><b>Array</b></p>

<p class="p2"><br></p>

<p class="p3"><span class="s1"><b>Superclass: </b><a href="ArrayedCollection.html"><b>ArrayedCollection</b></a></span></p>

<p class="p2"><br></p>

<p class="p4">Arrays are ArrayedCollections whose slots may contain any object. Arrays have a fixed maximum size beyond which they cannot grow. For expandable arrays, use the <a href="List.html"><span class="s2">List</span></a> class.</p>

<p class="p2"><br></p>

The help file generation system I developed originates from the OSX html generation mechanism. Really tricky, while it would be much easier to have a minimal content structure and a (minimal) css.

Marije knows perfectly what I am seeing, as I still found no time to improve linux compatibility.

This is a big issue, IMHO.

So, maybe for a general solution would be nice to consider both issued (GUI and IDE/help files)

Best

-a-

--------------------------------------------------

Andrea Valle

--------------------------------------------------

CIRMA - DAMS

Università degli Studi di Torino

--> http://www.cirma.unito.it/andrea/

--> http://www.myspace.com/andreavalle

--> andrea.valle@...

--------------------------------------------------

"

Think of it as seasoning

. noise [salt] is boring

. F(blah) [food without salt] can be boring

. F(noise, blah) can be really tasty

"

(Ken Perlin on noise)

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

[Christopher Frauenberger]

Hello,

I would all be for a cross platform solution that would integrate the  
GUI stuff in the lang. The best I have come across being free is Qt.  
Its easy to use, works well and predictable on various platforms and  
also has a nice look imo. Qt also provides a number of very  
convenient wrappers (for example sockets!!) that make life a lot  
easier for crossplatform things. It should be fairly easy to  
modularise the lexer, the App GUI and the GUI engine to make this  
happen.

Chris


On 2 May 2008, at 11:58, altern wrote:

> 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

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

[andrea valle-3]

There is also Juce: http://www.rawmaterialsoftware.com/juce/

(looks like cycling coded Max5 with it???)

Wow, damn' cool! :)

http://www.rawmaterialsoftware.com/ppm.php

Best

-a-

--------------------------------------------------

Andrea Valle

--------------------------------------------------

CIRMA - DAMS

Università degli Studi di Torino

--> http://www.cirma.unito.it/andrea/

--> http://www.myspace.com/andreavalle

--> andrea.valle@...

--------------------------------------------------

"

Think of it as seasoning

. noise [salt] is boring

. F(blah) [food without salt] can be boring

. F(noise, blah) can be really tasty

"

(Ken Perlin on noise)

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

[Florian Schmidt]

On Friday 02 May 2008, Dan Stowell wrote:

> 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...

I once started to hack a little crossplatform sclang editor (all you need is a
working C++ compiler, GNU make and Qt 4.x):

http://tapas.affenbande.org/qcollider_screen2.png

But due to the unavailableness of SuperCollider in my 64bit Ubuntu Hardy
installation i kinda lost sight of SC for the last few months.

When i tried to build it myself i stumbled over 64 bit compatibility issues :(

http://tapas.affenbande.org/qcollider/

Tarballs are available here. I don't have time ATM to hack on it seriously
even if i had a working SC install, but maybe someone likes to keep on
hacking it for the time being..

Regards,
Flo

--
Palimm Palimm!
http://tapas.affenbande.org
_______________________________________________
sc-users mailing list
sc-users@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-users

[Josh Parmenter]

My experience with Juce is limited, but it seems to be a bit resource hungry. I know Max 5 is MORE expensive GUI-wise (from a talk at SPARK), and if it looks that slick, there is probably a hit somewhere.

Personally, I don't care too much about how the GUI looks. But if it takes away at all from sound processing power, I think we are straying away from one of SCs main strengths.

Does anyone have any experience with wx? I know Audacity uses it, and it is easily cross-platform.

Josh

On May 2, 2008, at 5:04 AM, Andrea Valle wrote:

There is also Juce: http://www.rawmaterialsoftware.com/juce/

(looks like cycling coded Max5 with it???)

Wow, damn' cool! :)

http://www.rawmaterialsoftware.com/ppm.php

Best

-a-

--------------------------------------------------

Andrea Valle

--------------------------------------------------

CIRMA - DAMS

Università degli Studi di Torino

--> http://www.cirma.unito.it/andrea/

--> http://www.myspace.com/andreavalle

--> andrea.valle@...

--------------------------------------------------

"

Think of it as seasoning

. noise [salt] is boring

. F(blah) [food without salt] can be boring

. F(noise, blah) can be really tasty

"

(Ken Perlin on noise)

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

******************************************

/* Joshua D. Parmenter

http://www.realizedsound.net/josh/

“Every composer – at all times and in all cases – gives his own interpretation of how modern society is structured: whether actively or passively, consciously or unconsciously, he makes choices in this regard. He may be conservative or he may subject himself to continual renewal; or he may strive for a revolutionary, historical or social palingenesis." - Luigi Nono

*/

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