[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-dev] Towards SC 4

I too really like sclang, as a language, it's elegant and expressive.
But the implementation is not the best, and it lacks some important
stuff (mentioned already a lot of times...)
Perhaps it would make sense to create a new interpreter from scratch,
only building upon the existing syntax and extend it with namespaces
and modules etc, as well as cleaning away *some* of the syntactic
sugar? What about LLVM as backend? JIT compilation into real
super-fast machine code? That would be tasty :)

On Tue, Nov 12, 2013 at 8:49 PM, Scott Wilson <i@xxxxxxxxxxxxxx> wrote:
> 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/



-- 
/Jonatan
http://kymatica.com

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