Hi all,

I was just brainstorming and had the thought of a subcsound opcode.
The idea I had was that a CSOUND* could be held that runs a CSD as a
child Csound object.  Audio could be routed to/from via channels or
global audio in/out via params.  So something like:

asig1, asig2 ain
csound0, a1, a2 csound "someOther.csd", asig1, asig2
...
csound_chnset csound0, "someControlChannel", kval
csound_process csound0
kval2 csound_chnget csound0, "someReturnControl"

I imagine things like sr, kr, ksmps, etc. would be set from the parent
CSOUND*.  Ideally, the above would be implemented in csound6, such
that the type of the above "csound0" would be of type CSOUND.  The
opcodes above could then have OENTRY's like:

csound "(:csound,:a...)", "(:S,:a...)"
csound_chnset "", "(:csound,:S,:k)"
csound_chnget "k", "(:csound,:S)"
csound_event csound0, "i1 0 3 25"

(The above has a proposed alternate syntax for specifying arg lists
using a comma-separated list of types, which would be strings prefixed
by ":", surrounded by parentheses).

The thought for this is that one could use instruments in a CSD then
without worry about namespace clashes for instr numbers and other
things.  So imagine, a CSD that gets used for Cabbage or in CsoundQT,
could be reused as-is within any other CSD. (perhaps something like a
csound_instr_assign opcode could be used to map score statements to
instruments in subcsound memory spaces...)

On the one hand, I could imagine this being handy.  On the other hand,
I can imagine it also being a bit abused.  Anyways, I thought the idea
novel enough to ask here about.  Thoughts?

Thanks!
steven

------------------------------------------------------------------------------
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

At least part of this, namely instantiating sub-Csounds from within a
Csound performance, already can be done using the Lua opcodes.
LuaJIT/FFI could then be used to allocate buffers and manage looping
to set up under- and over-sampling.

Not sure if it's a good idea either...

Regards,
Mike

On Fri, Sep 21, 2012 at 1:14 PM, Steven Yi  wrote:
> Hi all,
>
> I was just brainstorming and had the thought of a subcsound opcode.
> The idea I had was that a CSOUND* could be held that runs a CSD as a
> child Csound object.  Audio could be routed to/from via channels or
> global audio in/out via params.  So something like:
>
> asig1, asig2 ain
> csound0, a1, a2 csound "someOther.csd", asig1, asig2
> ...
> csound_chnset csound0, "someControlChannel", kval
> csound_process csound0
> kval2 csound_chnget csound0, "someReturnControl"
>
> I imagine things like sr, kr, ksmps, etc. would be set from the parent
> CSOUND*.  Ideally, the above would be implemented in csound6, such
> that the type of the above "csound0" would be of type CSOUND.  The
> opcodes above could then have OENTRY's like:
>
> csound "(:csound,:a...)", "(:S,:a...)"
> csound_chnset "", "(:csound,:S,:k)"
> csound_chnget "k", "(:csound,:S)"
> csound_event csound0, "i1 0 3 25"
>
> (The above has a proposed alternate syntax for specifying arg lists
> using a comma-separated list of types, which would be strings prefixed
> by ":", surrounded by parentheses).
>
> The thought for this is that one could use instruments in a CSD then
> without worry about namespace clashes for instr numbers and other
> things.  So imagine, a CSD that gets used for Cabbage or in CsoundQT,
> could be reused as-is within any other CSD. (perhaps something like a
> csound_instr_assign opcode could be used to map score statements to
> instruments in subcsound memory spaces...)
>
> On the one hand, I could imagine this being handy.  On the other hand,
> I can imagine it also being a bit abused.  Anyways, I thought the idea
> novel enough to ask here about.  Thoughts?
>
> Thanks!
> steven
>
> ------------------------------------------------------------------------------
> Got visibility?
> Most devs has no idea what their production app looks like.
> Find out how fast your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219671;13503038;y?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Most flexible / straightforward alternative here I think would be a
host program that has an array of csound instances, which then accepts
requests via channels that cause it to create new csounds or close
them and add/ delete routes between the instances.

So for a simple example csounds[0] could ask its host to create
csounds[1] (and supply a string or file to use as csd), then
csounds[1] could eventually tell the host csounds[0] should be shut
down, as a simple way to modify instruments without gaps in audio.

But they could potentially be expanded to route audio between
themselves and such while operating in parallel (with minimal logistic
help on the part of the host).

I was working on something like this with guile scheme creating csound
instances via ffi a few months ago, until I got employed and busy. I
was implementing a master csound instance that did nothing but the
audio i/o, so that all the others sent audio to it or got audio from
it via channels, this was for seamless jack integration or continuous
output to a file without having to close / reopen.

This is totally doable with csound5, given someone with the patience
and time to actually complete it.

On Fri, Sep 21, 2012 at 11:18 AM, Michael Gogins
 wrote:
> At least part of this, namely instantiating sub-Csounds from within a
> Csound performance, already can be done using the Lua opcodes.
> LuaJIT/FFI could then be used to allocate buffers and manage looping
> to set up under- and over-sampling.
>
> Not sure if it's a good idea either...
>
> Regards,
> Mike
>
> On Fri, Sep 21, 2012 at 1:14 PM, Steven Yi  wrote:
>> Hi all,
>>
>> I was just brainstorming and had the thought of a subcsound opcode.
>> The idea I had was that a CSOUND* could be held that runs a CSD as a
>> child Csound object.  Audio could be routed to/from via channels or
>> global audio in/out via params.  So something like:
>>
>> asig1, asig2 ain
>> csound0, a1, a2 csound "someOther.csd", asig1, asig2
>> ...
>> csound_chnset csound0, "someControlChannel", kval
>> csound_process csound0
>> kval2 csound_chnget csound0, "someReturnControl"
>>
>> I imagine things like sr, kr, ksmps, etc. would be set from the parent
>> CSOUND*.  Ideally, the above would be implemented in csound6, such
>> that the type of the above "csound0" would be of type CSOUND.  The
>> opcodes above could then have OENTRY's like:
>>
>> csound "(:csound,:a...)", "(:S,:a...)"
>> csound_chnset "", "(:csound,:S,:k)"
>> csound_chnget "k", "(:csound,:S)"
>> csound_event csound0, "i1 0 3 25"
>>
>> (The above has a proposed alternate syntax for specifying arg lists
>> using a comma-separated list of types, which would be strings prefixed
>> by ":", surrounded by parentheses).
>>
>> The thought for this is that one could use instruments in a CSD then
>> without worry about namespace clashes for instr numbers and other
>> things.  So imagine, a CSD that gets used for Cabbage or in CsoundQT,
>> could be reused as-is within any other CSD. (perhaps something like a
>> csound_instr_assign opcode could be used to map score statements to
>> instruments in subcsound memory spaces...)
>>
>> On the one hand, I could imagine this being handy.  On the other hand,
>> I can imagine it also being a bit abused.  Anyways, I thought the idea
>> novel enough to ask here about.  Thoughts?
>>
>> Thanks!
>> steven
>>
>> ------------------------------------------------------------------------------
>> Got visibility?
>> Most devs has no idea what their production app looks like.
>> Find out how fast your code is with AppDynamics Lite.
>> http://ad.doubleclick.net/clk;262219671;13503038;y?
>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Got visibility?
> Most devs has no idea what their production app looks like.
> Find out how fast your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219671;13503038;y?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Multiple Csound instances in hosts is fine, but I think there is a
conceptual difference in this.  Having a sub-csound opcode would
provide the csound coder to more simply reuse other instruments within
CSD's. It'd also be able to call the csound opcode and control when
that audio processing gets done, then continue on with processing.

There is a problem of reusability with the way csound projects for
CsoundQT, Cabbage, and Csound for Live, all tend to use global space
for GUI's and which tend be used on their own.  This happens with FLTK
projects as well.  Part of what made this interesting to me was to
have a means to draw on using multiple projects without worry of
dependency and name clashing.

Anyways, it was just a thought.  I think it'd solve some problems, but
would probably open up others, so might be a zero net gain.  :P

steven


On Fri, Sep 21, 2012 at 7:32 PM, Justin Smith  wrote:
> Most flexible / straightforward alternative here I think would be a
> host program that has an array of csound instances, which then accepts
> requests via channels that cause it to create new csounds or close
> them and add/ delete routes between the instances.
>
> So for a simple example csounds[0] could ask its host to create
> csounds[1] (and supply a string or file to use as csd), then
> csounds[1] could eventually tell the host csounds[0] should be shut
> down, as a simple way to modify instruments without gaps in audio.
>
> But they could potentially be expanded to route audio between
> themselves and such while operating in parallel (with minimal logistic
> help on the part of the host).
>
> I was working on something like this with guile scheme creating csound
> instances via ffi a few months ago, until I got employed and busy. I
> was implementing a master csound instance that did nothing but the
> audio i/o, so that all the others sent audio to it or got audio from
> it via channels, this was for seamless jack integration or continuous
> output to a file without having to close / reopen.
>
> This is totally doable with csound5, given someone with the patience
> and time to actually complete it.
>
> On Fri, Sep 21, 2012 at 11:18 AM, Michael Gogins
>  wrote:
>> At least part of this, namely instantiating sub-Csounds from within a
>> Csound performance, already can be done using the Lua opcodes.
>> LuaJIT/FFI could then be used to allocate buffers and manage looping
>> to set up under- and over-sampling.
>>
>> Not sure if it's a good idea either...
>>
>> Regards,
>> Mike
>>
>> On Fri, Sep 21, 2012 at 1:14 PM, Steven Yi  wrote:
>>> Hi all,
>>>
>>> I was just brainstorming and had the thought of a subcsound opcode.
>>> The idea I had was that a CSOUND* could be held that runs a CSD as a
>>> child Csound object.  Audio could be routed to/from via channels or
>>> global audio in/out via params.  So something like:
>>>
>>> asig1, asig2 ain
>>> csound0, a1, a2 csound "someOther.csd", asig1, asig2
>>> ...
>>> csound_chnset csound0, "someControlChannel", kval
>>> csound_process csound0
>>> kval2 csound_chnget csound0, "someReturnControl"
>>>
>>> I imagine things like sr, kr, ksmps, etc. would be set from the parent
>>> CSOUND*.  Ideally, the above would be implemented in csound6, such
>>> that the type of the above "csound0" would be of type CSOUND.  The
>>> opcodes above could then have OENTRY's like:
>>>
>>> csound "(:csound,:a...)", "(:S,:a...)"
>>> csound_chnset "", "(:csound,:S,:k)"
>>> csound_chnget "k", "(:csound,:S)"
>>> csound_event csound0, "i1 0 3 25"
>>>
>>> (The above has a proposed alternate syntax for specifying arg lists
>>> using a comma-separated list of types, which would be strings prefixed
>>> by ":", surrounded by parentheses).
>>>
>>> The thought for this is that one could use instruments in a CSD then
>>> without worry about namespace clashes for instr numbers and other
>>> things.  So imagine, a CSD that gets used for Cabbage or in CsoundQT,
>>> could be reused as-is within any other CSD. (perhaps something like a
>>> csound_instr_assign opcode could be used to map score statements to
>>> instruments in subcsound memory spaces...)
>>>
>>> On the one hand, I could imagine this being handy.  On the other hand,
>>> I can imagine it also being a bit abused.  Anyways, I thought the idea
>>> novel enough to ask here about.  Thoughts?
>>>
>>> Thanks!
>>> steven
>>>
>>> ------------------------------------------------------------------------------
>>> Got visibility?
>>> Most devs has no idea what their production app looks like.
>>> Find out how fast your code is with AppDynamics Lite.
>>> http://ad.doubleclick.net/clk;262219671;13503038;y?
>>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> Got visibility?
>> Most devs has no idea what their production app looks like.
>> Find out how fast your code is with AppDynamics Lite.
>> http://ad.doubleclick.net/clk;262219671;13503038;y?
>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Got visibility?
> Most devs has no idea what their production app looks like.
> Find out how fast your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219671;13503038;y?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

 Would envisage recursion as a possibility?  In other words, having the csound opcode calling a CSD that contains that code line?
On 21 Sep 2012, at 22:46, Steven Yi wrote:

> Multiple Csound instances in hosts is fine, but I think there is a
> conceptual difference in this.  Having a sub-csound opcode would
> provide the csound coder to more simply reuse other instruments within
> CSD's. It'd also be able to call the csound opcode and control when
> that audio processing gets done, then continue on with processing.
> 
> There is a problem of reusability with the way csound projects for
> CsoundQT, Cabbage, and Csound for Live, all tend to use global space
> for GUI's and which tend be used on their own.  This happens with FLTK
> projects as well.  Part of what made this interesting to me was to
> have a means to draw on using multiple projects without worry of
> dependency and name clashing.
> 
> Anyways, it was just a thought.  I think it'd solve some problems, but
> would probably open up others, so might be a zero net gain.  :P
> 
> steven
> 
> 
> On Fri, Sep 21, 2012 at 7:32 PM, Justin Smith  wrote:
>> Most flexible / straightforward alternative here I think would be a
>> host program that has an array of csound instances, which then accepts
>> requests via channels that cause it to create new csounds or close
>> them and add/ delete routes between the instances.
>> 
>> So for a simple example csounds[0] could ask its host to create
>> csounds[1] (and supply a string or file to use as csd), then
>> csounds[1] could eventually tell the host csounds[0] should be shut
>> down, as a simple way to modify instruments without gaps in audio.
>> 
>> But they could potentially be expanded to route audio between
>> themselves and such while operating in parallel (with minimal logistic
>> help on the part of the host).
>> 
>> I was working on something like this with guile scheme creating csound
>> instances via ffi a few months ago, until I got employed and busy. I
>> was implementing a master csound instance that did nothing but the
>> audio i/o, so that all the others sent audio to it or got audio from
>> it via channels, this was for seamless jack integration or continuous
>> output to a file without having to close / reopen.
>> 
>> This is totally doable with csound5, given someone with the patience
>> and time to actually complete it.
>> 
>> On Fri, Sep 21, 2012 at 11:18 AM, Michael Gogins
>>  wrote:
>>> At least part of this, namely instantiating sub-Csounds from within a
>>> Csound performance, already can be done using the Lua opcodes.
>>> LuaJIT/FFI could then be used to allocate buffers and manage looping
>>> to set up under- and over-sampling.
>>> 
>>> Not sure if it's a good idea either...
>>> 
>>> Regards,
>>> Mike
>>> 
>>> On Fri, Sep 21, 2012 at 1:14 PM, Steven Yi  wrote:
>>>> Hi all,
>>>> 
>>>> I was just brainstorming and had the thought of a subcsound opcode.
>>>> The idea I had was that a CSOUND* could be held that runs a CSD as a
>>>> child Csound object.  Audio could be routed to/from via channels or
>>>> global audio in/out via params.  So something like:
>>>> 
>>>> asig1, asig2 ain
>>>> csound0, a1, a2 csound "someOther.csd", asig1, asig2
>>>> ...
>>>> csound_chnset csound0, "someControlChannel", kval
>>>> csound_process csound0
>>>> kval2 csound_chnget csound0, "someReturnControl"
>>>> 
>>>> I imagine things like sr, kr, ksmps, etc. would be set from the parent
>>>> CSOUND*.  Ideally, the above would be implemented in csound6, such
>>>> that the type of the above "csound0" would be of type CSOUND.  The
>>>> opcodes above could then have OENTRY's like:
>>>> 
>>>> csound "(:csound,:a...)", "(:S,:a...)"
>>>> csound_chnset "", "(:csound,:S,:k)"
>>>> csound_chnget "k", "(:csound,:S)"
>>>> csound_event csound0, "i1 0 3 25"
>>>> 
>>>> (The above has a proposed alternate syntax for specifying arg lists
>>>> using a comma-separated list of types, which would be strings prefixed
>>>> by ":", surrounded by parentheses).
>>>> 
>>>> The thought for this is that one could use instruments in a CSD then
>>>> without worry about namespace clashes for instr numbers and other
>>>> things.  So imagine, a CSD that gets used for Cabbage or in CsoundQT,
>>>> could be reused as-is within any other CSD. (perhaps something like a
>>>> csound_instr_assign opcode could be used to map score statements to
>>>> instruments in subcsound memory spaces...)
>>>> 
>>>> On the one hand, I could imagine this being handy.  On the other hand,
>>>> I can imagine it also being a bit abused.  Anyways, I thought the idea
>>>> novel enough to ask here about.  Thoughts?
>>>> 
>>>> Thanks!
>>>> steven
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> Got visibility?
>>>> Most devs has no idea what their production app looks like.
>>>> Find out how fast your code is with AppDynamics Lite.
>>>> http://ad.doubleclick.net/clk;262219671;13503038;y?
>>>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> 
>>> 
>>> 
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>> 
>>> ------------------------------------------------------------------------------
>>> Got visibility?
>>> Most devs has no idea what their production app looks like.
>>> Find out how fast your code is with AppDynamics Lite.
>>> http://ad.doubleclick.net/clk;262219671;13503038;y?
>>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> 
>> ------------------------------------------------------------------------------
>> Got visibility?
>> Most devs has no idea what their production app looks like.
>> Find out how fast your code is with AppDynamics Lite.
>> http://ad.doubleclick.net/clk;262219671;13503038;y?
>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> ------------------------------------------------------------------------------
> Got visibility?
> Most devs has no idea what their production app looks like.
> Find out how fast your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219671;13503038;y?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> _______________________________________________
> 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




------------------------------------------------------------------------------
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

It could, but I don't imagine it'd be a good idea. (Reminds me of
Ghostbusters, "Don't cross the streams.  It would be... bad..."  :D )

On Fri, Sep 21, 2012 at 10:55 PM, Victor Lazzarini
 wrote:
>  Would envisage recursion as a possibility?  In other words, having the csound opcode calling a CSD that contains that code line?
> On 21 Sep 2012, at 22:46, Steven Yi wrote:
>
>> Multiple Csound instances in hosts is fine, but I think there is a
>> conceptual difference in this.  Having a sub-csound opcode would
>> provide the csound coder to more simply reuse other instruments within
>> CSD's. It'd also be able to call the csound opcode and control when
>> that audio processing gets done, then continue on with processing.
>>
>> There is a problem of reusability with the way csound projects for
>> CsoundQT, Cabbage, and Csound for Live, all tend to use global space
>> for GUI's and which tend be used on their own.  This happens with FLTK
>> projects as well.  Part of what made this interesting to me was to
>> have a means to draw on using multiple projects without worry of
>> dependency and name clashing.
>>
>> Anyways, it was just a thought.  I think it'd solve some problems, but
>> would probably open up others, so might be a zero net gain.  :P
>>
>> steven
>>
>>
>> On Fri, Sep 21, 2012 at 7:32 PM, Justin Smith  wrote:
>>> Most flexible / straightforward alternative here I think would be a
>>> host program that has an array of csound instances, which then accepts
>>> requests via channels that cause it to create new csounds or close
>>> them and add/ delete routes between the instances.
>>>
>>> So for a simple example csounds[0] could ask its host to create
>>> csounds[1] (and supply a string or file to use as csd), then
>>> csounds[1] could eventually tell the host csounds[0] should be shut
>>> down, as a simple way to modify instruments without gaps in audio.
>>>
>>> But they could potentially be expanded to route audio between
>>> themselves and such while operating in parallel (with minimal logistic
>>> help on the part of the host).
>>>
>>> I was working on something like this with guile scheme creating csound
>>> instances via ffi a few months ago, until I got employed and busy. I
>>> was implementing a master csound instance that did nothing but the
>>> audio i/o, so that all the others sent audio to it or got audio from
>>> it via channels, this was for seamless jack integration or continuous
>>> output to a file without having to close / reopen.
>>>
>>> This is totally doable with csound5, given someone with the patience
>>> and time to actually complete it.
>>>
>>> On Fri, Sep 21, 2012 at 11:18 AM, Michael Gogins
>>>  wrote:
>>>> At least part of this, namely instantiating sub-Csounds from within a
>>>> Csound performance, already can be done using the Lua opcodes.
>>>> LuaJIT/FFI could then be used to allocate buffers and manage looping
>>>> to set up under- and over-sampling.
>>>>
>>>> Not sure if it's a good idea either...
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>> On Fri, Sep 21, 2012 at 1:14 PM, Steven Yi  wrote:
>>>>> Hi all,
>>>>>
>>>>> I was just brainstorming and had the thought of a subcsound opcode.
>>>>> The idea I had was that a CSOUND* could be held that runs a CSD as a
>>>>> child Csound object.  Audio could be routed to/from via channels or
>>>>> global audio in/out via params.  So something like:
>>>>>
>>>>> asig1, asig2 ain
>>>>> csound0, a1, a2 csound "someOther.csd", asig1, asig2
>>>>> ...
>>>>> csound_chnset csound0, "someControlChannel", kval
>>>>> csound_process csound0
>>>>> kval2 csound_chnget csound0, "someReturnControl"
>>>>>
>>>>> I imagine things like sr, kr, ksmps, etc. would be set from the parent
>>>>> CSOUND*.  Ideally, the above would be implemented in csound6, such
>>>>> that the type of the above "csound0" would be of type CSOUND.  The
>>>>> opcodes above could then have OENTRY's like:
>>>>>
>>>>> csound "(:csound,:a...)", "(:S,:a...)"
>>>>> csound_chnset "", "(:csound,:S,:k)"
>>>>> csound_chnget "k", "(:csound,:S)"
>>>>> csound_event csound0, "i1 0 3 25"
>>>>>
>>>>> (The above has a proposed alternate syntax for specifying arg lists
>>>>> using a comma-separated list of types, which would be strings prefixed
>>>>> by ":", surrounded by parentheses).
>>>>>
>>>>> The thought for this is that one could use instruments in a CSD then
>>>>> without worry about namespace clashes for instr numbers and other
>>>>> things.  So imagine, a CSD that gets used for Cabbage or in CsoundQT,
>>>>> could be reused as-is within any other CSD. (perhaps something like a
>>>>> csound_instr_assign opcode could be used to map score statements to
>>>>> instruments in subcsound memory spaces...)
>>>>>
>>>>> On the one hand, I could imagine this being handy.  On the other hand,
>>>>> I can imagine it also being a bit abused.  Anyways, I thought the idea
>>>>> novel enough to ask here about.  Thoughts?
>>>>>
>>>>> Thanks!
>>>>> steven
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Got visibility?
>>>>> Most devs has no idea what their production app looks like.
>>>>> Find out how fast your code is with AppDynamics Lite.
>>>>> http://ad.doubleclick.net/clk;262219671;13503038;y?
>>>>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>>
>>>>
>>>> --
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://www.michael-gogins.com
>>>> Michael dot Gogins at gmail dot com
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Got visibility?
>>>> Most devs has no idea what their production app looks like.
>>>> Find out how fast your code is with AppDynamics Lite.
>>>> http://ad.doubleclick.net/clk;262219671;13503038;y?
>>>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Got visibility?
>>> Most devs has no idea what their production app looks like.
>>> Find out how fast your code is with AppDynamics Lite.
>>> http://ad.doubleclick.net/clk;262219671;13503038;y?
>>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Got visibility?
>> Most devs has no idea what their production app looks like.
>> Find out how fast your code is with AppDynamics Lite.
>> http://ad.doubleclick.net/clk;262219671;13503038;y?
>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>> _______________________________________________
>> 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
>
>
>
>
> ------------------------------------------------------------------------------
> Got visibility?
> Most devs has no idea what their production app looks like.
> Find out how fast your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219671;13503038;y?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I think it is a good idea and might open yet unthought of possibilities.
Also a case of "use with extreme care" obviously,
but still a very nice idea I think.
best
Oeyvind

2012/9/21 Steven Yi :
> Multiple Csound instances in hosts is fine, but I think there is a
> conceptual difference in this.  Having a sub-csound opcode would
> provide the csound coder to more simply reuse other instruments within
> CSD's. It'd also be able to call the csound opcode and control when
> that audio processing gets done, then continue on with processing.
>
> There is a problem of reusability with the way csound projects for
> CsoundQT, Cabbage, and Csound for Live, all tend to use global space
> for GUI's and which tend be used on their own.  This happens with FLTK
> projects as well.  Part of what made this interesting to me was to
> have a means to draw on using multiple projects without worry of
> dependency and name clashing.
>
> Anyways, it was just a thought.  I think it'd solve some problems, but
> would probably open up others, so might be a zero net gain.  :P
>
> steven
>
>
> On Fri, Sep 21, 2012 at 7:32 PM, Justin Smith  wrote:
>> Most flexible / straightforward alternative here I think would be a
>> host program that has an array of csound instances, which then accepts
>> requests via channels that cause it to create new csounds or close
>> them and add/ delete routes between the instances.
>>
>> So for a simple example csounds[0] could ask its host to create
>> csounds[1] (and supply a string or file to use as csd), then
>> csounds[1] could eventually tell the host csounds[0] should be shut
>> down, as a simple way to modify instruments without gaps in audio.
>>
>> But they could potentially be expanded to route audio between
>> themselves and such while operating in parallel (with minimal logistic
>> help on the part of the host).
>>
>> I was working on something like this with guile scheme creating csound
>> instances via ffi a few months ago, until I got employed and busy. I
>> was implementing a master csound instance that did nothing but the
>> audio i/o, so that all the others sent audio to it or got audio from
>> it via channels, this was for seamless jack integration or continuous
>> output to a file without having to close / reopen.
>>
>> This is totally doable with csound5, given someone with the patience
>> and time to actually complete it.
>>
>> On Fri, Sep 21, 2012 at 11:18 AM, Michael Gogins
>>  wrote:
>>> At least part of this, namely instantiating sub-Csounds from within a
>>> Csound performance, already can be done using the Lua opcodes.
>>> LuaJIT/FFI could then be used to allocate buffers and manage looping
>>> to set up under- and over-sampling.
>>>
>>> Not sure if it's a good idea either...
>>>
>>> Regards,
>>> Mike
>>>
>>> On Fri, Sep 21, 2012 at 1:14 PM, Steven Yi  wrote:
>>>> Hi all,
>>>>
>>>> I was just brainstorming and had the thought of a subcsound opcode.
>>>> The idea I had was that a CSOUND* could be held that runs a CSD as a
>>>> child Csound object.  Audio could be routed to/from via channels or
>>>> global audio in/out via params.  So something like:
>>>>
>>>> asig1, asig2 ain
>>>> csound0, a1, a2 csound "someOther.csd", asig1, asig2
>>>> ...
>>>> csound_chnset csound0, "someControlChannel", kval
>>>> csound_process csound0
>>>> kval2 csound_chnget csound0, "someReturnControl"
>>>>
>>>> I imagine things like sr, kr, ksmps, etc. would be set from the parent
>>>> CSOUND*.  Ideally, the above would be implemented in csound6, such
>>>> that the type of the above "csound0" would be of type CSOUND.  The
>>>> opcodes above could then have OENTRY's like:
>>>>
>>>> csound "(:csound,:a...)", "(:S,:a...)"
>>>> csound_chnset "", "(:csound,:S,:k)"
>>>> csound_chnget "k", "(:csound,:S)"
>>>> csound_event csound0, "i1 0 3 25"
>>>>
>>>> (The above has a proposed alternate syntax for specifying arg lists
>>>> using a comma-separated list of types, which would be strings prefixed
>>>> by ":", surrounded by parentheses).
>>>>
>>>> The thought for this is that one could use instruments in a CSD then
>>>> without worry about namespace clashes for instr numbers and other
>>>> things.  So imagine, a CSD that gets used for Cabbage or in CsoundQT,
>>>> could be reused as-is within any other CSD. (perhaps something like a
>>>> csound_instr_assign opcode could be used to map score statements to
>>>> instruments in subcsound memory spaces...)
>>>>
>>>> On the one hand, I could imagine this being handy.  On the other hand,
>>>> I can imagine it also being a bit abused.  Anyways, I thought the idea
>>>> novel enough to ask here about.  Thoughts?
>>>>
>>>> Thanks!
>>>> steven
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Got visibility?
>>>> Most devs has no idea what their production app looks like.
>>>> Find out how fast your code is with AppDynamics Lite.
>>>> http://ad.doubleclick.net/clk;262219671;13503038;y?
>>>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>> ------------------------------------------------------------------------------
>>> Got visibility?
>>> Most devs has no idea what their production app looks like.
>>> Find out how fast your code is with AppDynamics Lite.
>>> http://ad.doubleclick.net/clk;262219671;13503038;y?
>>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Got visibility?
>> Most devs has no idea what their production app looks like.
>> Find out how fast your code is with AppDynamics Lite.
>> http://ad.doubleclick.net/clk;262219671;13503038;y?
>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Got visibility?
> Most devs has no idea what their production app looks like.
> Find out how fast your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219671;13503038;y?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://flyndresang.no/
http://www.partikkelaudio.com/
http://soundcloud.com/brandtsegg
http://soundcloud.com/t-emp

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net