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

Re: [sc-dev] Towards SC 4



Hi all,
remember me? ;)

On Tue, Nov 12, 2013 at 4:28 AM, Josh Parmenter <josh@xxxxxxxxxxxxxxxxx> wrote:

> In general, if we can make a plugin based language, I almost think
> everything beyond basic types should be quarks (or a quark like structure)
> where a bare bones language is provided, a set of recommended tools to
> install, and the rest as extras. Overwriting methods I think should not be
> allowed as well (while subclasses certainly can).

I think this is a very good idea. Core language with basic types and
the really essential stuff, plugins/modules for the rest. Hopefully
dynamic (load at runtime) and scoped: module = import("MyModule"); foo
= module.MyClass();

Of course subclasses must be able to override methods, but I agree we
should not allow any *overwriting* of methods.

> In SC 2, there was no language / synth separation. While this made something
> much easier (NRT, triggering items based on signal, etc. without an OSC
> responder), I think the benefit of having one lang instance control many
> servers (local and remote) and the general safety that the division brought
> about in SC 3 was a strength. Some thoughts and mediation between the two
> approaches, I think, should be one of the primary considerations with SC 4.

Not sure it's related, but it would be great to have:
- sample precise control of the synth
- possibility to do 1-sample delay feedback, either per synthdef or
part of a synthdef. Then it would be possible to create "anything" dsp
without writing a new UGen.
- oversampling, also per synthdef or part of synthdef.

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