Hi there !

I have just finished writing the oscit library (Open Sound Control
Interface Transfer: http://rubyk.org/oscit) and am writing an open
source patcher called rubyk (http://rubyk.org). Rubyk is a general
realtime signal processing tool (complete rewrite coming to an end)
and has already been used for movement recognition and other signal
processing tasks. It is network based and has been embedded in tiny
ARM based hardware.

I am just discovering Csound and I have the feeling that it could be
very easy to load opcodes in rubyk by wrapping them in rubyk's own
message passing system. The OENTRY could be used to create
corresponding inlets and outlets and we would just need to make sure
all data is available before starting data processing...

This is not a work I'd like to start right away, but since audio
processing will probably be needed in rubyk someday, I prefer to
investigate the solutions that avoid reinventing the wheel.

So my first question is: how much dependency is there on the actual
Csound environment ? Would it be possible to provide a minimal
environment (memory allocation, global variables, ??) to run opcodes ?

And my second question: is this a bad idea ?

Thanks for any idea on the subject.

Gaspard

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hello Gaspard!

I am unaware of anyone using opcodes by themselves outside of csound.
The tricky thing is that many of the opcodes will use the CSOUND* to
get information like sampling rate, control rate, current time, etc.
Also, many will use functions held in the CSOUND* for things like
looking up created f-tables.  You may be able to create a CSOUND*,
then manually create OENTRY's and run the opcodes with the CSOUND* as
long as you continue to update the things csound would like the
current time. My guess is if you are careful in picking which opcodes
to use, you might be able to get it to work but it may have some
headaches.

Hope that helps!
steven

On Sat, Jan 9, 2010 at 5:01 PM, Gaspard Bucher  wrote:
> Hi there !
>
> I have just finished writing the oscit library (Open Sound Control
> Interface Transfer: http://rubyk.org/oscit) and am writing an open
> source patcher called rubyk (http://rubyk.org). Rubyk is a general
> realtime signal processing tool (complete rewrite coming to an end)
> and has already been used for movement recognition and other signal
> processing tasks. It is network based and has been embedded in tiny
> ARM based hardware.
>
> I am just discovering Csound and I have the feeling that it could be
> very easy to load opcodes in rubyk by wrapping them in rubyk's own
> message passing system. The OENTRY could be used to create
> corresponding inlets and outlets and we would just need to make sure
> all data is available before starting data processing...
>
> This is not a work I'd like to start right away, but since audio
> processing will probably be needed in rubyk someday, I prefer to
> investigate the solutions that avoid reinventing the wheel.
>
> So my first question is: how much dependency is there on the actual
> Csound environment ? Would it be possible to provide a minimal
> environment (memory allocation, global variables, ??) to run opcodes ?
>
> And my second question: is this a bad idea ?
>
> Thanks for any idea on the subject.
>
> Gaspard
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Steven !

I had a look at the CSOUND environment:

  static const CSOUND cenviron_ = {
    /* ----------------- interface functions (322 total) ----------------- */

Ouch! (By the way, the csoundCore.h file says:
    /* Csound API function pointers (320 total) */

Hmmm... It looks like the the CSOUND struct wraps a whole operating
system, with thread managent, file acces, etc. But it might also be
possible to provide a binary compatible CSOUND struct with wrappers
for the methods that are needed by the opcodes we want to use and
gently wrapping the 300+ API calls as they are needed... There would
then be a list of "compatible" opcodes.

This is not that scary and it could be quite fun...

Thanks for the feedback.

Gaspard



On Mon, Jan 11, 2010 at 5:22 AM, Steven Yi  wrote:
> Hello Gaspard!
>
> I am unaware of anyone using opcodes by themselves outside of csound.
> The tricky thing is that many of the opcodes will use the CSOUND* to
> get information like sampling rate, control rate, current time, etc.
> Also, many will use functions held in the CSOUND* for things like
> looking up created f-tables.  You may be able to create a CSOUND*,
> then manually create OENTRY's and run the opcodes with the CSOUND* as
> long as you continue to update the things csound would like the
> current time. My guess is if you are careful in picking which opcodes
> to use, you might be able to get it to work but it may have some
> headaches.
>
> Hope that helps!
> steven
>
> On Sat, Jan 9, 2010 at 5:01 PM, Gaspard Bucher  wrote:
>> Hi there !
>>
>> I have just finished writing the oscit library (Open Sound Control
>> Interface Transfer: http://rubyk.org/oscit) and am writing an open
>> source patcher called rubyk (http://rubyk.org). Rubyk is a general
>> realtime signal processing tool (complete rewrite coming to an end)
>> and has already been used for movement recognition and other signal
>> processing tasks. It is network based and has been embedded in tiny
>> ARM based hardware.
>>
>> I am just discovering Csound and I have the feeling that it could be
>> very easy to load opcodes in rubyk by wrapping them in rubyk's own
>> message passing system. The OENTRY could be used to create
>> corresponding inlets and outlets and we would just need to make sure
>> all data is available before starting data processing...
>>
>> This is not a work I'd like to start right away, but since audio
>> processing will probably be needed in rubyk someday, I prefer to
>> investigate the solutions that avoid reinventing the wheel.
>>
>> So my first question is: how much dependency is there on the actual
>> Csound environment ? Would it be possible to provide a minimal
>> environment (memory allocation, global variables, ??) to run opcodes ?
>>
>> And my second question: is this a bad idea ?
>>
>> Thanks for any idea on the subject.
>>
>> Gaspard
>>
>> ------------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast and easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net