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