[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sc-dev] Towards SC 4
I think the idea of a js synthdef interface (and others) is good, but I think a switch to js entirely would be a serious step backwards in language design. I somehow like sclang. There's something good about it, I think. There have been attempts at other language bindings, but despite that sclang has remained the centre of gravity.
Besides, even if we could agree to switch to another language, how likely is it that we could actually get any consensus on which one? ;-)
S.
On 12 Nov 2013, at 16:48, Josh Parmenter <josh@xxxxxxxxxxxxxxxxx> wrote:
> That makes more sense to me... I though you meant having SynthDefs be in js, but everything else be in SC.
> Again, I think if we design the server interface with this kind of expandability in mind,then I don't see why just about any language couldn't tap into it. I think it is more about what needs to be exposed, how to expose it and how to control it.
> Thanks for clearing that up...
> Josh
>
> /*
> Josh Parmenter
> www.realizedsound.net/josh
> */
>
>> On Nov 12, 2013, at 8:38 AM, "Kuivila, Ronald" <rkuivila@xxxxxxxxxxxx> wrote:
>>
>> Hi Josh,
>>
>> The js idea would be for people who don't do SC. It wouldn't be to write js code, just a portable way to create SynthDefs that would demonstrate how
>> to do this in a better-known language.
>>
>> RJK
>>
>>> On Nov 12, 2013, at 11:23 AM, Josh Parmenter wrote:
>>>
>>> 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/
>>
>>
>> _______________________________________________
>> 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/