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

[0001]

Provided this thread can still accept two more cents, maybe it would  
be interesting to work towards a little crossplatform self-contained  
IDE (Squeak and Processing come to mind), which could retain Document,  
the wiki and most of the functionality of the mac version.
Regarding file formats, storing everything in plain text, using  
something like markdown or a wiki syntax could still allow graphical  
editing and would feel natural for all programmers used to mixing  
markup with code eg. in python or java. This would possibly require  
focusing the editor capabilities on simple text styling and leaving  
layout control to the program.

...

gerard






El May 4, 2008, a las 3:29 PM, Julian Rohrhuber escribió:

> Andrea wrote:
>>
>> So, each IDE could define a strategy for reading/writing xml (or
>> whatever) help files.
>> On Mac we could think of a parser creating the usual NSRTFsomething.
>> Nothing changes for the user while reading.
>> Writing the help file would require to the dev a more structured
>> approach. But that's how it goes.
>> You can write by hand the xml (wiki markup), we can write a GUI
>> providing the required fields etc.
>>
>> It would be easy to autogenerate help files from sources.
>> It would be easy to create pdfs. I have not update the SC help book
>> because it's a pain to deal with html parsing.
>>
>
> I try to compress some issues of this discussion (in the light of
> numerous past discussions over the years):
>
> (1) should there be one single format for all sc files (excluding
> classes maybe) or should there be a documentation format and a
> "normal" one? It would be desirable to have a single format to
> maintain interoperability for all files.
>
> (2) the rich text approach (in whatever format) can seem weird to
> people who come from either more toolbench like or more terminal
> oriented practices. Rich text, on the other hand is very natural for
> those who come from literary and visual practices. It would be
> desirable to keep this literary programming style and make it
> available on all systems.
>
> (3) It is tedious to write and maintain well structured helpfiles
> without some kind of structural separation of layout and content. The
> reflective character of sclang should be reflected in the helpfiles,
> too.
>
> The various suggestions concerning these issues seem to be difficult
> because there are contradictions between these three needs.
>
>
>
> In Den Haag, James McCartney suggested Markdown as an alternative
> format (http://en.wikipedia.org/wiki/Markdown) This is good for
> interoperability, but in itself does not really solve (2) and (3).
>
> It would be possible to build on Lyx and use LaTeX as a format
> (http://en.wikipedia.org/wiki/LyX). Interesting, but LyX is really
> not very responsive. This is a great disadvantage. But of course it
> would be very interesting, and fidel to the original idea of literate
> programming to have mathematical (or any other kind of) formulas.
>
> Earlier, we had hoped that the html formatting would become more
> structured with leopard. I have no idea how it looks on leopard.
>
> If we dropped (1), it would be possible to write a little editor in
> SC that has forms which can be used to fill in help file content and
> save it some appropriately structured format (XML, LaTeX or
> whatever). But to do this for all files is a lot of work which would
> have to be done by many people and not just by a few.
>
> Still the question would be open of how to make the other files work
> on all systems.
>
> If we dropped (2), the other ones would become more easy, but I think
> it is not worth it, considering the loss.
>
>
> --
>
>
>
>
>
> .
> _______________________________________________
> 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 Sunday 04 May 2008 10:38:57 Andrea Valle wrote:
> Ah, now I remeber, Marije noticed once that editing ah HTML generated
> from Helper with Amaya and Quanta created strange results:

I believe someone else noticed that my self-edited file created strange
results.
It looked fine in my browser :)
This experience though somewhat holds me back from just editing HTML
helpfiles, since I don't know what they will look like.

The main problem are the apple tabs that are inserted, which are not HTML
standard, I think, unless you actually use the special code tag, which allows
you to insert text as is.
There is no way for me to check whether the inserted apple tabs line up or
not, and I have found no consistent behaviour to them.
Cocoa also inserts too many paragraph signs, where the text actually just runs
through, causing large space between lines in the emacs html browser.
Worse even, in some help files code lines are split between lines, which
causes problems executing the code:
        - the line runs over and the end of the code is missing
        - a comment runs over and a bit of the comment is interpreted as code,
causing an error.
The solution is to turn the file into an editing mode (pressing E), and delete
the spurious line breaks.

I did try nvu, but I believe it crashed the last time I tried it, and now I
can't find it anymore in the Debian repository...

So in short:
* HTML works nice for the links and all,
* the rendering is not great with a good number of help files, causing
problems with viewing,
* but worse, code execution.
* editing existing Help files is horrible, if you can even find the right
lines. alternative WYSIWYG editors do not always do the job.
* writing help files is simplified by Andrea's Helper and Autohelper class
(even if I did not try it out extensively yet), but not yet perfect.


sincerely,
Marije

>
> http://www.nabble.com/NetAddr-td15814734i20.html#a15887328
>
> Best
>
> -a-
>
> On 4 May 2008, at 16:30, Andrea Valle wrote:
> >> Although I know some people prefer it, there's little real need to
> >> hand code html for SC doc. Nvu is for instance a cross-platform
> >> OSS WYSIWYG editor, which seems in my casual tests to deal with
> >> the existing help files fine.
> >
> > Ah, so you are saying that e.g. on Linux Marije can edit html help
> > files generated by my doc classes with Nvu?
> > Because, if this is a shared solution, I can re-switch to the
> > original, mac-centric, implementation which worked much better
> > from  the mac user perspective (as it used actively Document).
> > At that point the linuxers/windowers generate a file from the help
> > classes, and then edit it in with Nvu. Solved.
> >
> > Best
> >
> > -a-
> >
> >> S.
> >>
> >> On 4 May 2008, at 13:41, Andrea Valle wrote:
> >>>> Hey Andrea,
> >>>>
> >>>> Can you expand a little on how this is a problem? Do you just
> >>>> mean the
> >>>> WYSIWYG editing on Mac? I agree that cross-platform Document
> >>>> support
> >>>> would be great, but the help system isn't so dependant on that.
> >>>>
> >>>> S.
> >>>
> >>> Scott, I'll try to re-elaborate.
> >>>
> >>> One very strong point with SC2 has always been that help files
> >>> were valid documents. You can open them, evaluate them, save your
> >>> document as help files.
> >>> The format was rtf.
> >>> Now, in SC3 there was the problem of generalizing the help files
> >>> while retaining the same (fantastic) flexibility.
> >>> So (correct me please), the idea was to switch to HTML. On  Mac
> >>> this has been quite easy by NSIdontknow technology, which allows
> >>> to keep rtf-like formatting while saving to html, and to open
> >>> html by converting it into rtf-like format. An HTML help files is
> >>> converted into a Document instance.
> >>> The fact is that  in this way  HTML is the original help file
> >>> format. This is better if compared to the more problematic rtf as
> >>> in SC2. Still, HTML is not a good format to ensure automatic
> >>> conversion to SC document.
> >>> It's good for Mac, not for Linux (Marije has noticed many times),
> >>> and in psycollider you simply strip away all the formatting by
> >>> calling "html to code" command.
> >>> But the main problem is not for reading the HTML (at the end, one
> >>> can always use psycollider method: strip away all), but for
> >>> writing/editing a help file.
> >>> HTML could a good choice if it were clean.
> >>> But the cocoa HTML sources are awful. If you're on mac, you have
> >>> not to deal with the problem. You use Document for editing, and
> >>> that's all.
> >>> What about to write a help file if your on linux/win? On other
> >>> platforms, it's really complicated.
> >>> Probably, the fact is that HTML as an original format is not a
> >>> good choice.
> >>>
> >>> So, there are two points:
> >>> 1. HTML is  not a good choice
> >>> 2. cocoa HTML is dirty, as it focuses on visual instead of
> >>> content structure
> >>>
> >>> The classes I proposed are very tricky and try to generalize over
> >>> the mac approach by assembling an autogenerated (dirty) HTML.
> >>> Significantly, they have not solved Marije's problems.
> >>> Still I don't know of devs writing help files while on win, so I
> >>> don't know, but I guess they have the same troubles.
> >>> Because the problem is the (cocoa) HTML.
> >>>
> >>> Instead, one can think of a minimal XML format as the original
> >>> format.
> >>> E.g. for SinOsc (just to give an idea)
> >>>
> >>> <ugen>
> >>> <name>SinOsc</name>
> >>> <shortDescirption>interpolating sine wavetable oscillator</
> >>> shortDescirption>
> >>>
> >>> <syntax>SinOsc.ar(freq, phase, mul, add)</syntax>
> >>>
> >>> <longDescription>
> >>> Sinusoidal oscillator; a sine tone.
> >>>
> >>> Note: This is the same as Osc except that the table has already
> >>> been fixed as a sine table of 8192 entries.
> >>> </longDescription>
> >>>
> >>> <args>
> >>> <arg1>freq - frequency in Hertz</arg1>
> >>> <arg2>
> >>> phase - phase offset or modulator in radians
> >>> </arg2>
> >>> </args>
> >>> <example>
> >>> { SinOsc.ar(200, 0, 0.5) }.play;
> >>>
> >>>
> >>> // modulate freq
> >>> { SinOsc.ar(XLine.kr(2000, 200), 0, 0.5) }.play;
> >>>
> >>> // modulate freq
> >>> { SinOsc.ar(SinOsc.ar(XLine.kr(1, 1000, 9), 0, 200, 800), 0,
> >>> 0.25) }.play;
> >>>
> >>>
> >>> // modulate phase
> >>> { SinOsc.ar(800, SinOsc.ar(XLine.kr(1, 1000, 9), 0, 2pi),
> >>> 0.25) }.play;
> >>> </example>
> >>> </ugen>
> >>>
> >>> This infos could be eventually but not necessarily inserted into
> >>> sources (as in that first attempts I tried for autodocs).
> >>>  I'm not a fan of xml, and more I'm an ignorant onthe topic:
> >>> maybe just a wiki mark up approach could be enough for us.
> >>> The main point is that the original help sources would not be in
> >>> the "dirty" html.
> >>>
> >>> So, each IDE could define a strategy for reading/writing xml (or
> >>> whatever) help files.
> >>> On Mac we could think of a parser creating the usual
> >>> NSRTFsomething. Nothing changes for the user while reading.
> >>> Writing the help file would require to the dev a more structured
> >>> approach. But that's how it goes.
> >>> You can write by hand the xml (wiki markup), we can write a GUI
> >>> providing the required fields etc.
> >>>
> >>> It would be easy to autogenerate help files from sources.
> >>> It would be easy to create pdfs. I have not update the SC help
> >>> book because it's a pain to deal with html parsing.
> >>>
> >>> Just 2c
> >>>
> >>> Best
> >>>
> >>> -a-

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

[Scott Wilson-8]

On 4 May 2008, at 20:05, Gregory Cornelius wrote:
>
> My criticism of your tutorial, Scott, is that it jumps into working  
> with audio too quickly.

The irony is that it has actually been criticised for not doing it  
fast enough! For new users without a programming background I do think  
it's very useful to get them tinkering with sound quickly. That's  
often the 'hook'. Lots of discussion of OOP theory can be a little dry  
in the absence of sound. I base this observation on years of teaching  
this stuff, FWIW.

So in 'Getting Started' (which I consider a work in progress, btw) I  
try to do that, but keep slipping in bits of how things 'actually work'.
>
>
> First, I think we should add a section on inheritance in the "Intro-
> to-Objects."
>

If you'd like to propose some text we could look at adding it. ;-)

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

[Gregory Cornelius]

Julian, I was not suggesting that one begin by explaining all of the  
possibilities.   Rather, I prefer starting with the core and leaving  
shortcuts until later in the learning process.   At the least, I  
think it would be clearer if  "function.play;" contained the  
arguments for the server.

        {SinOsc.ar(440, 0, 0.1)}.play(s);

Perhaps, the syntax shortcut for arguments is a simpler example.    
By using the more verbose "arg",  the functionality of the code is  
more explicit.  For a beginner the more familiarity one can develop  
with dot syntax, objects, and their methods,  the better.

In my view, there are the methods of scraping complexity away.    For  
example, what are the ramifications of not loading the GUI for the  
local server at launch.  I am not suggesting remove the Local server  
completely.   Just that the two servers add a layer of unnecessary  
complexity for someone new to SC.    Addressing multiple servers  
really is an advanced topic that just gets in the way for  
inexperienced users.



On May 4, 2008, at 4:02 PM, Julian Rohrhuber wrote:

>>
>>> --- I also think that the shortcut for playing sound should be
>>> avoided in a tutorial as should the shortcuts for arguments in
>>> functions.   These shortcuts are great for someone who is
>>> experienced, but when I started they led to a lack of understanding
>>> of how SC actually works.
>>>
>>> {SinOsc.ar(0, 440, 0.1)}.play;
>>>
>>
>> Here I totally agree with you. An enormous caveat should be put in
>> tutorials about {}.play.
>
> I'm not sure about this at all. Trying to explain how sc "really"
> works may actually be one of the sources of problems. From my
> experience it is better to keep away from implementation details at
> the beginning and instead offer immediate insights into the relation
> text-sound, together with explaining general and abstract programming
> concepts that are valid across different languages.
>
> Usually it has been less difficult to explain the relation { }.play
> and SynthDef than the fact that you can play a synth either by synth
> messages, synth objects or event objects, each with its special
> limitations.
> --
>
>
>
>
>
> .
> _______________________________________________
> 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]

In my view, there are the methods of scraping complexity away.    For  

example, what are the ramifications of not loading the GUI for the  

local server at launch.  I am not suggesting remove the Local server  

completely.   Just that the two servers add a layer of unnecessary  

complexity for someone new to SC.    Addressing multiple servers  

really is an advanced topic that just gets in the way for  

inexperienced users.

oh well, in my startup I deleted internal server GUI. i never use it and it's not crossplatform...:)

-a-

On May 4, 2008, at 4:02 PM, Julian Rohrhuber wrote:

--- I also think that the shortcut for playing sound should be

avoided in a tutorial as should the shortcuts for arguments in

functions.   These shortcuts are great for someone who is

experienced, but when I started they led to a lack of understanding

of how SC actually works.

{SinOsc.ar(0, 440, 0.1)}.play;

Here I totally agree with you. An enormous caveat should be put in

tutorials about {}.play.

I'm not sure about this at all. Trying to explain how sc "really"

works may actually be one of the sources of problems. From my

experience it is better to keep away from implementation details at

the beginning and instead offer immediate insights into the relation

text-sound, together with explaining general and abstract programming

concepts that are valid across different languages.

Usually it has been less difficult to explain the relation { }.play

and SynthDef than the fact that you can play a synth either by synth

messages, synth objects or event objects, each with its special

limitations.

-- 

.

_______________________________________________

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

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

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

[Gregory Cornelius]

>
> So in 'Getting Started' (which I consider a work in progress, btw) I
> try to do that, but keep slipping in bits of how things 'actually  
> work'.

Interesting...I will stop obsessing.

> If you'd like to propose some text we could look at adding it. ;-)
>
> S.
> _______________________________________________
>

I was working on this when I rediscovered the class browser and the  
Internal-snooping helpfile.    SC and its documentation is so deep.


[inheritance.rtf]

---

{\rtf1\mac\ansicpg10000\cocoartf824\cocoasubrtf470
{\fonttbl\f0\fswiss\fcharset77 Helvetica-Bold;\f1\fswiss\fcharset77 Helvetica;\f2\fnil\fcharset77 Monaco;
}
{\colortbl;\red255\green255\blue255;\red0\green0\blue255;\red0\green0\blue191;\red191\green0\blue0;
}
\deftab560
\pard\pardeftab560\ql\qnatural

\f0\b\fs36 \cf0 Classes, Sub-classes, and Inheritance\
\

\f1\b0\fs24 Sub-classes (children) are more specialized versions of classes (parents).  By default, each subclass inherits the properties and behaviors of classes higher in the hierarchy.   Even for end users, this is significant because an object may have more functionality than the documentation suggests due to inheritance.   \
\
In the documentation, the superclass is usually listed at the top of the document, which allows the user to trace upwards through the hierarcy.   For example, {\field{\*\fldinst{HYPERLINK "SC://Array"}}{\fldrslt \cf2 Array}} is a subclass of {\field{\*\fldinst{HYPERLINK "SC://Collection"}}{\fldrslt \cf2 Collection}}.\
\
All classes are subclasses of {\field{\*\fldinst{HYPERLINK "SC://Object"}}{\fldrslt \cf2 Object}}.   There is a GUI for browsing the class hierarchy.   To start at the top of the tree one can execute the following.   \
\
\pard\pardeftab560\ql\qnatural

\f2\fs18 \cf3 Object\cf0 .browse;
\f1\fs24 \
\
The SC language also includes methods for quickly printing information about an object to the post window including those that are inherited.\
\

\f2\fs18 \cf3 List\cf0 .dumpFullInterface;
\f1\fs24 \
\
See also:   {\field{\*\fldinst{HYPERLINK "SC://Internal-Snooping"}}{\fldrslt \cf2 Internal-Snooping}}\
\
\pard\pardeftab560\ql\qnatural

\f0\b \cf0 Examples:
\f1\b0 \
\

\f2\fs18 (\
a = \cf3 Array\cf0 .new(3);\
a.add(1);\
a.add(2);\
a.add(3);\
)\
\
\pard\pardeftab560\ql\qnatural
\cf3 Array\cf0 .dumpInterface;    \cf4 //  .reverse is one of the methods for Array\cf0 \
\
a.reverse;  \
\
\cf3 Collection\cf0 .dumpInterface;   \cf4 // Array not only has its own methods but also inherits from Collection\cf0 \
\
a.sum;   \cf4 // .sum is inherited from Collection\cf0 \
\
\cf3 Object\cf0 .dumpInterface;\
\
a.postln;  \cf4 // .postln is inherited from Object\cf0 \
\pard\pardeftab560\ql\qnatural

\f1\fs24 \cf0 \
\
\
\
\
\
\
}

---

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

[Tim Mortimer]

Yes admittedly i haven't explored this thoroughly, but im kind of busy enough with csound, python, & now wx. as well as trying to earn money etc etc.

The reason i'd prefer more examples is that before i actually learn SC, i want to find out if there is any point.

the things that i'm interested in that csound presently denies me are

1) resynthesis format possibilities other than phase vocoding (ATS, Loris, & SDIF / hetro in Csound all have either some windows specific issue preventing implementation / correct functionality - at least in my case, or are in need of some sort of update / overhaul.)

2) gui options - particularly that might help with organising a database of algorithmic elements, or scoring pieces for instruments that lave a large number of parametric dependencies.

IF i saw examples to the effect that "yes, these types of things are on offer in SC", then i would embark on any documented tutorial / help / getting started route.

I am the minority starting user here i'd assume - i'm already across OOP & another DSP language in csound.

To misquote the Sex Pistols - I know what i want, i'm just not 100% sure how to get it.

If it looked like SC would help, i'd learn it.

No gripes, no complaints - the general observation that "i'd be far more likely to pick SC up if i had a mac" stands - & was the main point i was making - just providing the answer to a fair enough question.

James Harkins-2 wrote:

However... the help is all HTML and readable in Psycollider... so,  
you looked in the examples but didn't look at the help page? There  
are tutorials listed right at the top.

[James Harkins-2]

On May 4, 2008, at 7:58 PM, Tim Mortimer wrote:

The reason i'd prefer more examples is that before i actually learn SC, i

want to find out if there is any point.

the things that i'm interested in that csound presently denies me are 

1) resynthesis format possibilities other than phase vocoding (ATS, Loris, &

SDIF / hetro in Csound all have either some windows specific issue

preventing implementation / correct functionality - at least in my case, or

are in need of some sort of update / overhaul.)

I haven't explored recent assist in supercollider, so I'm the wrong person to ask. Josh Parmenter has done an ATS implementation, and there was some discussion recently about SDIF (which is not available yet in sc to my knowledge). Not sure about Loris.

Josh, are your ATS ugens available in Windows?

2) gui options - particularly that might help with organising a database of

algorithmic elements, or scoring pieces for instruments that lave a large

number of parametric dependencies.

This, yes, absolutely you can do it in supercollider.

The chucklib part of my extension library is basically a database of algorithmic elements -- arbitrary functions and patterns can be stored for different purposes, and process prototypes can be written using object oriented principles and then reused with different parameters for different musical contexts. You're also free to define your own storage classes if you aren't satisfied with the ones that come with the package. I have a small browser GUI that is SwingOSC compatible (works in Windows), with keyboard commands for navigation and performing some key operations quickly.

"Parametric dependencies" could mean several different things. I'm not sure if you mean synthesis parameters, parameters controlling compositional routines, or something else altogether.

No gripes, no complaints - the general observation that "i'd be far more

likely to pick SC up if i had a mac" stands - & was the main point i was

making - just providing the answer to a fair enough question.

Yes, of course -- it's an entirely reasonable answer.

Still, Andrea has a point that even if the documentation were perfect, sc is always going to take some tenacity to learn. Developers can work on removing really stupid obstacles (like examples in a platform-specific format), and the amount of energy going into this conversation shows that the community cares a great deal about these issues. But no amount of work on the "product" is going to make it a "download, launch, get blown away instantly" package.

I would say it shouldn't be impossible to learn sc using Windows. It may be a bit tougher, but the help browser and class browser do work in Windows and they are invaluable. (A few buttons in the class browser don't work because of the lack of Document support but you don't need those features to look through lists of classes and methods to find something interesting.)

If it is perceived to be impossible or not worth the effort, then that's where we need some good feedback to go and fix things.

hjh

: 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."  -- Whitman

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

[Josh Parmenter]

On May 4, 2008, at 8:08 PM, James Harkins wrote:

On May 4, 2008, at 7:58 PM, Tim Mortimer wrote:

The reason i'd prefer more examples is that before i actually learn SC, i

want to find out if there is any point.

the things that i'm interested in that csound presently denies me are 

1) resynthesis format possibilities other than phase vocoding (ATS, Loris, &

SDIF / hetro in Csound all have either some windows specific issue

preventing implementation / correct functionality - at least in my case, or

are in need of some sort of update / overhaul.)

I haven't explored recent assist in supercollider, so I'm the wrong person to ask. Josh Parmenter has done an ATS implementation, and there was some discussion recently about SDIF (which is not available yet in sc to my knowledge). Not sure about Loris.

Josh, are your ATS ugens available in Windows?

I'm not sure if they are included in the latest Psycollider or not, but they were at one time.

There was some discussion over the past couple of weeks about SDIF, SPEAR and others. They are, of course, all possible. The work just needs to be done. 

I'm re-working some things in ATS this weekend actually. It may be possible to build a small library of functions that could be used for any sin / noise based re-synthesis.

Josh

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

/* 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

[Josh Parmenter]

Sorry... I was mistaken about the Windows versions of Ats stuff. I just noticed a Windows readme in the sc3-plugins source. Looks like everything in sc3-plugins except AY and Stk compile just fine. So, no problem running those on windows.

Josh

On May 4, 2008, at 8:08 PM, James Harkins wrote:

On May 4, 2008, at 7:58 PM, Tim Mortimer wrote:

The reason i'd prefer more examples is that before i actually learn SC, i

want to find out if there is any point.

the things that i'm interested in that csound presently denies me are 

1) resynthesis format possibilities other than phase vocoding (ATS, Loris, &

SDIF / hetro in Csound all have either some windows specific issue

preventing implementation / correct functionality - at least in my case, or

are in need of some sort of update / overhaul.)

I haven't explored recent assist in supercollider, so I'm the wrong person to ask. Josh Parmenter has done an ATS implementation, and there was some discussion recently about SDIF (which is not available yet in sc to my knowledge). Not sure about Loris.

Josh, are your ATS ugens available in Windows?

2) gui options - particularly that might help with organising a database of

algorithmic elements, or scoring pieces for instruments that lave a large

number of parametric dependencies.

This, yes, absolutely you can do it in supercollider.

The chucklib part of my extension library is basically a database of algorithmic elements -- arbitrary functions and patterns can be stored for different purposes, and process prototypes can be written using object oriented principles and then reused with different parameters for different musical contexts. You're also free to define your own storage classes if you aren't satisfied with the ones that come with the package. I have a small browser GUI that is SwingOSC compatible (works in Windows), with keyboard commands for navigation and performing some key operations quickly.

"Parametric dependencies" could mean several different things. I'm not sure if you mean synthesis parameters, parameters controlling compositional routines, or something else altogether.

No gripes, no complaints - the general observation that "i'd be far more

likely to pick SC up if i had a mac" stands - & was the main point i was

making - just providing the answer to a fair enough question.

Yes, of course -- it's an entirely reasonable answer.

Still, Andrea has a point that even if the documentation were perfect, sc is always going to take some tenacity to learn. Developers can work on removing really stupid obstacles (like examples in a platform-specific format), and the amount of energy going into this conversation shows that the community cares a great deal about these issues. But no amount of work on the "product" is going to make it a "download, launch, get blown away instantly" package.

I would say it shouldn't be impossible to learn sc using Windows. It may be a bit tougher, but the help browser and class browser do work in Windows and they are invaluable. (A few buttons in the class browser don't work because of the lack of Document support but you don't need those features to look through lists of classes and methods to find something interesting.)

If it is perceived to be impossible or not worth the effort, then that's where we need some good feedback to go and fix things.

hjh

: 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."  -- Whitman

_______________________________________________
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