[Cs-dev] a-rate channels
| Date | 2013-08-30 05:35 |
| From | Alex Weiss |
| Subject | [Cs-dev] a-rate channels |
| Attachments | None None |
Hi list
I remember a discussion here a while back about channel mechanisms in the cs6 API and potential changes to them. So I was wondering what the current state is and if there are recommended best practices.
Specifically, what I'm trying to do is to route a-rate signals out of csound for external processing, then send the processed signals back to csound for further processing in the same k-cycle. I was looking at the chn* family of opcodes to accomplish this -- is this encouraged or is there a better way?
Thanks, Alex |
| Date | 2013-08-31 03:36 |
| From | Steven Yi |
| Subject | Re: [Cs-dev] a-rate channels |
Hi Alex,
Doing csound->host->csound arbitrarily within a k-cycle seems like
something that would be very good to have a standard way to do it. My
initial thought is of an older idea I had of a host opcode, one that
hosts would use that could insert into a CSD. Csound could call the
opcode like any other, and the opcode would be configured to call into
the host. So something like:
aout host "someCallbackName", aval, kval, ival ...
and when creating a Csound instance, the host could do things like:
csoundSetHostCallback("someCallback1", functionPointer, hostData);
csoundSetHostCallback("someCallback2", functionPointer, hostData);
csoundSetHostCallback("someCallback3", functionPointer, hostData);
and registered functions would get called something like:
outData = functionPointer(hostData, inData);
where inData and outData may be of the same type of struct, one that
holds values from/to csound.
I don't know if that would work well, or maybe if it's just better for
the host to create their own opcodes and use the existing Csound
registration functions for registering opcodes.
Thoughts?
steven
On Fri, Aug 30, 2013 at 12:35 AM, Alex Weiss |
| Date | 2013-08-31 06:31 |
| From | Alex Weiss |
| Subject | Re: [Cs-dev] a-rate channels |
| Attachments | None None |
Hi Steven,
Funny -- your approach is quite literally exactly what I had in mind (except I was going to use numbers instead of names). I do think that this would be a very valuable addition to the API as it makes integration with other synthesis systems and plug-in architectures a lot easier.
Alex On Fri, Aug 30, 2013 at 7:36 PM, Steven Yi <stevenyi@gmail.com> wrote: Hi Alex, |
| Date | 2013-08-31 15:44 |
| From | Andres Cabrera |
| Subject | Re: [Cs-dev] a-rate channels |
| Attachments | None None |
Or maybe just add more types to the invalue/outvalue opcodes? They are already callback based. Cheers,Andrés On Fri, Aug 30, 2013 at 10:31 PM, Alex Weiss <alexweiss86@gmail.com> wrote:
|
| Date | 2013-08-31 16:32 |
| From | Alex Weiss |
| Subject | Re: [Cs-dev] a-rate channels |
| Attachments | None None |
The problem with that approach is that it is non-blocking, so round-tripping in the same k-cycle might get tricky. On Aug 31, 2013 7:45 AM, "Andres Cabrera" <mantaraya36@gmail.com> wrote:
|
| Date | 2013-08-31 17:44 |
| From | Andres Cabrera |
| Subject | Re: [Cs-dev] a-rate channels |
| Attachments | None None |
The invalue and outvalue opcodes are blocking. The opcode will not return until the callback function has returned. Cheers, Andrés
On Sat, Aug 31, 2013 at 8:32 AM, Alex Weiss <alexweiss86@gmail.com> wrote:
|