Sorry for the OT, it will be the last.

On Thu, Oct 31, 2013 at 12:00:32PM -0400, Steven Yi wrote:
> [...]  Yes, this idea is not new altogether. [...]

Ok, it was the intent of my message. Your words

    [...] The idea here would be to introduce something
    besides TREE, something that can be queried and modified. Perhaps
    something like UGEN* could work here.  This might be able to be used
    to extend the existing INSTR system and still maintain the efficient
    runtime performance of the existing system (big block alloc, oplists,
    etc.).
    [...]

have made me think about the Virtual UGen, but it is not the case.

> OOP systems will allow graph changes, as does Max/PD.  There is a
> similar system in Roger Dannenberg's Aura which allows generator graph
> modifications in realtime. It uses a concept of Instruments and Ugens,

don't forget the excellent Extempore

> but the Instr wraps the ugen.  Instr may be a single ugen, or have C++
> to do it's own processing and use other ugens directly. This sounds
> similar to the VUG in Incudine, just swapping the implementation
> language from Lisp to C++.

It sounds similar to the nested DSPs but not to the VUG. Practically
there aren't ugens, opcodes or instruments in Incudine; I use the word
"ugen" only for tradition. It is another history, unrelated to the papers.

> As for passing UGens as parameters to other Ugens or Instruments, I
> have been going down this route in a Clojure synthesizer I have been
> working on, as well as been drafting some ideas on how to do the same
> with Csound.  In the Clojure synth, I'm working with maintaining
> abstractions as conventions.  I.e. what would be a ugen in another
> language is just a plain, higher-order function that returns a closure
> that is the perf-time function.  It gives it the ability to close over
> data to use internally, much like how Csound opcodes have internal
> state that only the performance function has access to.  Mutable data
> sources such as MIDI or OSC would be injected into an audio function
> as just another audio function that read from a buffer that the source
> wrote to.  I was looking at writing an article about dependency
> injection in computer music systems, discussing how the event
> abstraction and processing need to support arguments that are ugens,
> but I haven't had time yet.

I have written the code for the inference of the performance time
variables during the pre-compilation of a VUG to get efficient code.
VUG and VUG-MACRO are performance time by default.

> Anyways, some further brainstorming.  Thanks for reminding me about
> Incudine; I had only checked out the code a while back, but had not
> the time to look at if I needed to find other dependencies, etc.  I'll
> try downloading and compiling/running in my Debian VM this weekend.

The next week I'll add a command line tool to use the unix environment.
The first execution generates the compiled files for the (possibly multiple)
lisp and score files. Perhaps it works with Blue.

Tito

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net