Hi there!

I had an idea the other night..."exporting" the precious csound opcode
collection to other
software environments (max/msp in my case..).
I know there's the csound API and csound~ etc. but my idea is to use
csound's opcodes
(primarily signal generators/modifiers) as standalone building blocks
without the whole
orchestra/parser engine.

This shouldn't be too hard, should it (besides file i/o, inter-opcode
communication, etc.)?

So here's my question:
Any tips on where to look in csound's source code on initializing opcodes,
setting up
the CSOUND struct and getting the opcode's arguments?

...in the end, i imagine this as an automated wrapper spitting out
ready-to-compile max/msp (pd)
externals :)

many thx in advance,
jan.

-- 
View this message in context: http://www.nabble.com/how-to-access-opcodes-without-the-csound-engine---tp24343855p24343855.html
Sent from the Csound - Dev mailing list archive at Nabble.com.


------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

This is a good idea, and I have thought about it myself. It would take
a fair amount of work, but it might be well worth while. There are
several issues

(1) The opcodes might have to be "wrapped" in some abstraction layer,
like a C++ virtual class for opcodes that exposes all the opcode
hooks. But the existing opcode table might actually be enough, as it
already contains all the function pointers and in/out type codes. So,
such an abstraction layer could be quite thin, a skinny C++ class that
plugs the opcode structure and function pointers into a more
accessible form, perhaps with template metaprogramming to
automagically create getters/setters for all the in/out values.

(2) Many opcodes call back into Csound, and often directly access
objects in Csound. So, that part of the Csound "host:" would have to
be re-implemented in a wrapper by the new host. Actually, I don't
think doing this is necessarily so hard, especially since a lot of
opcodes do this via the Csound API now, and the rest could be changed
to use the API. Then all that is required is to re-implement those
Csound API calls in the new host. A lot of this is easy - rates,
messaging, etc. Function table access, not so hard. Memory management,
a  bit harder. I don't know what else would be required.

(3) The opcodes are designed to run in a particular kind of DSP graph
which is fairly sophisticated, and very old "Unix C" style code.
Presumably, you are not talking about re-implementing this, but
rather, you want to use the Csound opcodes in some OTHER DSP graph.

I have thought about doing this with Lua, to enable the re-use of
Csound opcodes in a new Lua-based computer music system.

I believe Gabriel Maldonado has a project to wrap the Csound opcodes
in C++, to faciitate this kind of thing. I do not know the current
status of this project.

Hope this helps,
Mike



On 7/5/09, janbam  wrote:
>
> Hi there!
>
> I had an idea the other night..."exporting" the precious csound opcode
> collection to other
> software environments (max/msp in my case..).
> I know there's the csound API and csound~ etc. but my idea is to use
> csound's opcodes
> (primarily signal generators/modifiers) as standalone building blocks
> without the whole
> orchestra/parser engine.
>
> This shouldn't be too hard, should it (besides file i/o, inter-opcode
> communication, etc.)?
>
> So here's my question:
> Any tips on where to look in csound's source code on initializing opcodes,
> setting up
> the CSOUND struct and getting the opcode's arguments?
>
> ...in the end, i imagine this as an automated wrapper spitting out
> ready-to-compile max/msp (pd)
> externals :)
>
> many thx in advance,
> jan.
>
> --
> View this message in context:
> http://www.nabble.com/how-to-access-opcodes-without-the-csound-engine---tp24343855p24343855.html
> Sent from the Csound - Dev mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> 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

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On 09/07/2009, Michael Gogins  wrote:
> This is a good idea, and I have thought about it myself. It would take
> a fair amount of work, but it might be well worth while. There are
> several issues
>
> (1) The opcodes might have to be "wrapped" in some abstraction layer,
> like a C++ virtual class for opcodes that exposes all the opcode
> hooks. But the existing opcode table might actually be enough, as it
> already contains all the function pointers and in/out type codes. So,
> such an abstraction layer could be quite thin, a skinny C++ class that
> plugs the opcode structure and function pointers into a more
> accessible form, perhaps with template metaprogramming to
> automagically create getters/setters for all the in/out values.
>
> (2) Many opcodes call back into Csound, and often directly access
> objects in Csound. So, that part of the Csound "host:" would have to
> be re-implemented in a wrapper by the new host. Actually, I don't
> think doing this is necessarily so hard, especially since a lot of
> opcodes do this via the Csound API now, and the rest could be changed
> to use the API. Then all that is required is to re-implement those
> Csound API calls in the new host. A lot of this is easy - rates,
> messaging, etc. Function table access, not so hard. Memory management,
> a  bit harder. I don't know what else would be required.

Binary compatibility with the real csound if you don't plan on
rebuilding the opcodes for each new host.


Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net