Hi All,

I had a random thought the other day about introducing another
abstraction besides Instruments to Csound.  The idea is to have
something called Patch that if defined would be automatically run and
only allow one instance.  The internal idea is that it would have
slightly different internals and be optimized for allowing live
modifications to a graph at runtime.  Opcodes would be wrapped and
instead of large block allocations of instances as in instruments, it
would allocate memory enough per opcode.  My thought is that it would
be less-efficient but more flexible, and be suitable for host
applications to use.  I imagine two use cases:

1. Max/PD types of applications
2. Using scripting languages to create graphs of opcodes in realtime

Also, the runtime profile would be a little different than instruments
today. Instruments currently flatten out graphs into an ordered list.
The use of wrappers to opcodes would maintain the tree of opcode
dependencies, thus allowing reordering.

An alternative ideas to introducing a new abstraction is to allow
having instruments that maintain graphs as well as the flattened
lists, such that a graph change would trigger a recompile of the
flattened list/vars. 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.).

Anyways, some random thoughts that I thought I'd write out here. To
note, as some of you know  I have been working on code to allow use of
csound opcodes by themselves outside of the normal csound runtime
context, and it largely works (still issues to solve). It uses a
wrapper for each opcode to hold a reference to an OENTRY, as well as
holds memory for the opcode's struct and for variables that are
pointed to from opcodes.  Perhaps that code could be a place to start
from.

Thanks!
steven

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

you know, I was thinking the same thing today, but in a slightly different way. My thought was
to allow perf-time in global space, which would be a one-off instrument.

Funny the coincidence, isn't it?

On 30 Oct 2013, at 21:48, Steven Yi wrote:

> Hi All,
> 
> I had a random thought the other day about introducing another
> abstraction besides Instruments to Csound.  The idea is to have
> something called Patch that if defined would be automatically run and
> only allow one instance.  The internal idea is that it would have
> slightly different internals and be optimized for allowing live
> modifications to a graph at runtime.  Opcodes would be wrapped and
> instead of large block allocations of instances as in instruments, it
> would allocate memory enough per opcode.  My thought is that it would
> be less-efficient but more flexible, and be suitable for host
> applications to use.  I imagine two use cases:
> 
> 1. Max/PD types of applications
> 2. Using scripting languages to create graphs of opcodes in realtime
> 
> Also, the runtime profile would be a little different than instruments
> today. Instruments currently flatten out graphs into an ordered list.
> The use of wrappers to opcodes would maintain the tree of opcode
> dependencies, thus allowing reordering.
> 
> An alternative ideas to introducing a new abstraction is to allow
> having instruments that maintain graphs as well as the flattened
> lists, such that a graph change would trigger a recompile of the
> flattened list/vars. 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.).
> 
> Anyways, some random thoughts that I thought I'd write out here. To
> note, as some of you know  I have been working on code to allow use of
> csound opcodes by themselves outside of the normal csound runtime
> context, and it largely works (still issues to solve). It uses a
> wrapper for each opcode to hold a reference to an OENTRY, as well as
> holds memory for the opcode's struct and for variables that are
> pointed to from opcodes.  Perhaps that code could be a place to start
> from.
> 
> Thanks!
> steven
> 
> ------------------------------------------------------------------------------
> 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
> https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie




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

Yes, I think it's good we're interrogating the engine and looking for
ways to extend it. :)  For perf code in instr 0 space, that one might
be tricky to figure out how to turn something off, as well as to
figure out process ordering.  Either way, we should probably collect
all these ideas and look at tradeoffs to get some momentum on what to
do next.

On Wed, Oct 30, 2013 at 6:09 PM, Victor Lazzarini
 wrote:
> you know, I was thinking the same thing today, but in a slightly different way. My thought was
> to allow perf-time in global space, which would be a one-off instrument.
>
> Funny the coincidence, isn't it?
>
> On 30 Oct 2013, at 21:48, Steven Yi wrote:
>
>> Hi All,
>>
>> I had a random thought the other day about introducing another
>> abstraction besides Instruments to Csound.  The idea is to have
>> something called Patch that if defined would be automatically run and
>> only allow one instance.  The internal idea is that it would have
>> slightly different internals and be optimized for allowing live
>> modifications to a graph at runtime.  Opcodes would be wrapped and
>> instead of large block allocations of instances as in instruments, it
>> would allocate memory enough per opcode.  My thought is that it would
>> be less-efficient but more flexible, and be suitable for host
>> applications to use.  I imagine two use cases:
>>
>> 1. Max/PD types of applications
>> 2. Using scripting languages to create graphs of opcodes in realtime
>>
>> Also, the runtime profile would be a little different than instruments
>> today. Instruments currently flatten out graphs into an ordered list.
>> The use of wrappers to opcodes would maintain the tree of opcode
>> dependencies, thus allowing reordering.
>>
>> An alternative ideas to introducing a new abstraction is to allow
>> having instruments that maintain graphs as well as the flattened
>> lists, such that a graph change would trigger a recompile of the
>> flattened list/vars. 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.).
>>
>> Anyways, some random thoughts that I thought I'd write out here. To
>> note, as some of you know  I have been working on code to allow use of
>> csound opcodes by themselves outside of the normal csound runtime
>> context, and it largely works (still issues to solve). It uses a
>> wrapper for each opcode to hold a reference to an OENTRY, as well as
>> holds memory for the opcode's struct and for variables that are
>> pointed to from opcodes.  Perhaps that code could be a place to start
>> from.
>>
>> Thanks!
>> steven
>>
>> ------------------------------------------------------------------------------
>> 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
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> Dr Victor Lazzarini
> Senior Lecturer
> Dept. of Music
> NUI Maynooth Ireland
> tel.: +353 1 708 3545
> Victor dot Lazzarini AT nuim dot ie
>
>
>
>
> ------------------------------------------------------------------------------
> 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
> https://lists.sourceforge.net/lists/listinfo/csound-devel

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

Hi Tito,

Good to hear from you!  Yes, this idea is not new altogether.  Many
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,
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++.

My interest in the proposal is to have this capability in Csound (as
well as furthering Csound the language/system to offer more functional
programming facilities).

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 did however want to see Csound's event system updated to use the
type system.  With that, we could then store values in p-fields
besides floats and strings.  The result would allow us to do
dependency injection both from the event opcode and the score. For
example:

event "i", 1, 0, 4, linseg(440, p3, 800) , .25
i1 0 4 linseg(440,p3, 800) .25
i1 0 4 440 .25  ; instr would be designed to take scalars in too

Might express the same things from the ORC and SCO sides where
OpInstances could be the type of the variable storing the linseg.

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.

Cheers!
steven


On Thu, Oct 31, 2013 at 3:39 AM, Tito Latini  wrote:
> Steven Yi wrote:
>> Hi All,
>>
>> I had a random thought the other day about introducing another
>> abstraction besides Instruments to Csound.  The idea is to have
>> something called Patch that if defined would be automatically run and
>> only allow one instance.  The internal idea is that it would have
>> slightly different internals and be optimized for allowing live
>> modifications to a graph at runtime.  Opcodes would be wrapped and
>> instead of large block allocations of instances as in instruments, it
>> would allocate memory enough per opcode.  My thought is that it would
>> be less-efficient but more flexible, and be suitable for host
>> applications to use.  I imagine two use cases:
>>
>> 1. Max/PD types of applications
>> 2. Using scripting languages to create graphs of opcodes in realtime
>>
>> Also, the runtime profile would be a little different than instruments
>> today. Instruments currently flatten out graphs into an ordered list.
>> The use of wrappers to opcodes would maintain the tree of opcode
>> dependencies, thus allowing reordering.
>>
>> An alternative ideas to introducing a new abstraction is to allow
>> having instruments that maintain graphs as well as the flattened
>> lists, such that a graph change would trigger a recompile of the
>> flattened list/vars. 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.).
>
> Hi,
>
> It is not new for me and probably you know it (I remember your gentle
> message after the announcement of Incudine [1]). I have invented the
> Virtual UGen and it is not only for opcodes; a VUG contains lisp code
> and/or other nested VUGs. Besides, a parameter of a DSP (similar to an
> instrument in Csound) can be another DSP. It is also possible to define
> nested DSPs but currently the interface is low level and to review.
>
> All this is on-the-fly.
>
> Tito Latini
>
> [1] http://incudine.sourceforge.net
>
> ------------------------------------------------------------------------------
> 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
> https://lists.sourceforge.net/lists/listinfo/csound-devel

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

I'll need to look further into Incudine, but the VUG does seem similar
to the Aura Instr to me.  Perhaps I'll see something different once I
read through the VUG and VUG-MACRO code. As for OT, I don't mind
myself as I enjoy discussing engines and designs, but maybe better to
take off list.  :P

I have scheduled to try installing/running Incudine tomorrow.  If
Incudine can read in Csound .sco files (at least, the form that Blue
generates, which has no loops or other SCO lang features, just notes),
I can add a mode to Blue to generate SCO and run with a user-defined
program (i.e. incudine, any other program that runs SCO). That could
possibly allow using a lot of Blue's score features, though the user
would have to not use certain things like the new AudioLayers I'm
working on, or particular soundObjects like the Instrument
SoundObject.  Anyways, it would be nice to explore some possibilities.

Cheers!
steven

On Thu, Oct 31, 2013 at 4:12 PM, Tito Latini  wrote:
> 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
> https://lists.sourceforge.net/lists/listinfo/csound-devel

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

If the defining feature you are talking about is that it remains Lisp
code and it isn't compiled, then yes, they are different. But if the
idea is that there is an abstraction that can act as a unit generator
and be connected to others, as well as can act as an instrument and be
scheduled by an event system, or instantiated arbitrarily by the user
in a live coding setting (REPL), then both systems share this.

I looked briefly just now and the VUG code looks very nice to me. It
is nice that you can write VUG's at runtime.  I also like the the
clarity of the VUG definitions.  The code I write for Clojure looks
similar but I'm doing a let-binding and closing over to return a
performance function. It's pretty generic and flexible but It adds a
bit of extra lines which I've wondered if I should work around with a
macro or leave as-is as any Clojure programmer would get it. Anyways,
I've been enjoying Lisps a lot lately for their dynamic nature and
workflow with REPL's and think it is a big plus.  (Though, I'm finding
Csound with ReadOrc at runtime shoud be dynamic enough to cover most
of my use cases too.)

As for the scofile->lispfile, nice. :)  One of the target features for
Blue 3.x is to make adding modules very easy for 3rd party.  It would
be easy enough to do a separate Incudine module for Blue that would
add all the features specifically for Incudine (a play button, program
options dialogs for configuraiton, extra editors for editing of
Incudine project files, etc.).  Blue parses SCO text as Note objects
but does very little processing, so it should be easy to generate a
sco file that can work with Incudine.

The 3.x series hasn't started yet though as I'm waiting to finish 2.6
to create the branch.  I also need to clarify the API's and stabilize
them to make them appropriate for 3rd party use.  If you'd like to
collaborate on something, we could do a feature branch and keep it
separate until the 3.x series gets going.  The modules could then be
easily separated out and installed through the Netbeans module manager
that I'll enable in 3.x, and packages could be added to the
auto-update site once I get that going too. Also, I just realized if
we're going so far as to create a module, it'd be easy enough to get
the generated Notelist from Blue and write the s-expr's out directly
if that'd be better for the Incudine side.

Anyways, we've both gone OT now.  I'd be happy to continue the
conversation though off list. I'll email further when I have a chance
to setup Incudine in the VM tomorrow and can give it a try.

Thanks!
steven

On Fri, Nov 1, 2013 at 7:21 PM, Tito Latini  wrote:
> Only to close the circle
>
> On Fri, Nov 01, 2013 at 04:00:54PM -0400, Steven Yi wrote:
>> I'll need to look further into Incudine, but the VUG does seem similar
>> to the Aura Instr to me. [...]
>
> Aura:
>
>    [...] at run-time, allocation is simple, fast and atomic because
>    initialization of sub-objects is handled by compiled code [...]
>
> Spammer's tool:
>
> There aren't sub-objects handled by compiled code.
>
> Aura:
>
>    [...] communication among primitives within the sound object is
>    handled by compiled code [...]
>
> Spammer's tool:
>
> Idem; there aren't sound objects and a VUG is not compiled code.
>
> Aura:
>
>    [...] Alternatively, a single primitive can be "wrapped" with the
>    appropriate sound object interface, allowing it to be connected
>    to other sound object.
>
> Spammer's tool:
>
> There aren't primitives; lisp code remains lisp code without wrappers
> or other functions.
>
>> I have scheduled to try installing/running Incudine tomorrow.  If
>> Incudine can read in Csound .sco files (at least, the form that Blue
>
> mmm 
>
> ------------------------------------------------------------------------------
> 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
> https://lists.sourceforge.net/lists/listinfo/csound-devel

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