[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sc-dev] Towards SC 4
I don't see why Lang <-> Server communication, or perhaps even the scsynth API couldn't be in another language (perhaps scsynth can handle OSC and js? Personally, I cringe at this, but maybe?).
But I think one environment mixing two languages is confusing. Within SC, I personally think it would be best avoided. Also, if we requires you to know js (for example) to write a Synth description, it seems to me that there is an argument just to make the whole thing js.
Another idea I had this morning - what is we were able to make the server / synth object even leaner, perhaps only starting and running a single synth graph? Then, each different synth graph is it's own server?
I'm on my phone, so I will explain more later, but I think I am thinking that something like the Synth construct from SC 2 gets interpreted and launches a server with the graph that is created, and other Synth objects create new server instances?
Obviously this would mean paring the server down to something that can be started very quickly, or set into a waiting state, but it would move things more toward an audio plugin type model (like VST or AU), and part of the server model / API would be accepting audio and control input, values for Function arguments, and audio and control output.
Not sure how feasible (or in the end desirable) that might be, but it might be another approach worth considering for the synth side of things.
/*
Josh Parmenter
www.realizedsound.net/josh
*/
> On Nov 12, 2013, at 7:06 AM, "Kuivila, Ronald" <rkuivila@xxxxxxxxxxxx> wrote:
>
> Hi all,
>
> I love the sclang, but....
>
> SC evangelism would be helped if certain pieces of SC functionality (the UGen library and SynthDefs to start) were implemented in one or another mainstream
> language.
>
> Perhaps in javascript so you could define and download synthdefs from a browser (or a js object in MAX) and then run them via OSC.
>
>
>
> RJK
>
>
>> On Nov 12, 2013, at 9:48 AM, Josh Parmenter wrote:
>>
>> Yes, I believe we really need to keep the idea of SC as a language intact (though possibly the role of the lang changes, as mentioned earlier). HOWEVER, if we keep a lang / synth divide, developing a clear API that other languages can tap into is certainly a possible goal.
>> As far as licensing, with SC 4, this would be a fresh project in my mind. Fresh code start (which is part of the point). If things like AU / VST are wanted, we should consider whether or not licensing differences are warranted as well. This may mean not reusing ANY code from SC 3 at all, but I think that should be part of the discussion. (iPhone store as well).
>> 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-dev mailing list
>>
>> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>> archive: https://listarc.bham.ac.uk/marchives/sc-dev/
>> search: https://listarc.bham.ac.uk/lists/sc-dev/search/
>
>
> _______________________________________________
> sc-dev mailing list
>
> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> archive: https://listarc.bham.ac.uk/marchives/sc-dev/
> search: https://listarc.bham.ac.uk/lists/sc-dev/search/
_______________________________________________
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/