Re: [sc-dev] Towards SC 4

[Jonatan Liljedahl <lijon@xxxxxxxxxxxx>]

Regarding realtime, of course it's nice with short and predictable
latency (for reacting on events such as OSC and MIDI), but other than
that I don't think the demands are very high. Scheduling of server
events are timestamped, so as long as they are sent before the
timestamp expires it will be no problem. Sames goes for OSC and MIDI
output. I guess the main thing that needs to be avoided is if there
are any stuff happening that would block the execution for too long,
like some GC implementations does. I know SC's GC is designed to avoid
this, but OTOH instead we have *lots* of other ways to block the
single-threaded sclang - so it doesn't help much, especially since
sclang is quite slow compared even to  modern javascript engines.

I like sclang pretty much, when it comes to the actual language
(except some obvious shortcomings like lack of namespaces and dynamic
module loading). But there are quite some big benefits of using a well
known standard existing language.

On Tue, Nov 12, 2013 at 2:47 PM, Scott Wilson <i@xxxxxxxxxxxxxx> wrote:
>
> On 12 Nov 2013, at 13:42, Bovermann Till <till.bovermann@xxxxxxxx> wrote:
>
> (2) What about (officially) extending an existing state of the art
> programming language such as Ruby ( https://www.ruby-lang.org/en/ ) or
> JavaScript with
> (a) guaranteed realtime waiting (as crucial for musical tasks) and
> (b) synthdef generation?
>
> I have the feeling that Ruby is pretty close to SClang, however it lacks
> both the rt features and the extensive music-oriented library of SC.
>
>
> Be aware that those languages (or individual implementations of them) may or
> may not be realtime friendly.
>
> S.



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