[Csnd] plugin opcode limitations...
Date | 2018-08-24 23:49 |
From | Forrest Curo |
Subject | [Csnd] plugin opcode limitations... |
I've done a simple (adds 2 numbers in init phase & outputs an increasing count in k time) plugin opcode. That is, if I put in a line like iresult kresult opty 2,2 I get iresult = 4, and kresult rapidly increasing every time When I start putting other things I'd like to play with into the plugin code, some of these work (ie an array of integers) while others (starting to initialize the allegro graphics library) don't. That is, I still get an .so file but it stops working as an opcode. What are the limits on this sort of thing? (ie Can I start a new pthread in the opcode & have one branch return to run csound while the other goes on processing? |
Date | 2018-08-25 01:08 |
From | Forrest Curo |
Subject | Re: [Csnd] plugin opcode limitations... |
Ah! No libraries containing c++ code? On Fri, Aug 24, 2018 at 3:49 PM, Forrest Curo <treegestalt@gmail.com> wrote:
|
Date | 2018-08-25 10:52 |
From | Victor Lazzarini |
Subject | Re: [Csnd] plugin opcode limitations... |
There is no limitations as to libraries you might use in your plugin code. If you give more details we may be able to help. When you say ‘it stops working as an opcode’, do you mean it does not get loaded? If that is the case, there may be reasons to do with linking (if the linked libraries are not found for instance). ======================== Prof. Victor Lazzarini Dean of Arts, Celtic Studies, and Philosophy, Maynooth University, Maynooth, Co Kildare, Ireland Tel: 00 353 7086936 Fax: 00 353 1 7086952 > On 25 Aug 2018, at 01:08, Forrest Curo |
Date | 2018-08-25 17:22 |
From | Forrest Curo |
Subject | Re: [Csnd] plugin opcode limitations... |
Okay, I think I've got it, no problem. I'd left out a needed "-l" in the compilation line. This compilation line seemed to work (everything required for the csound libraries themselves) ----------- forrest@salvage:~/c$ gcc -O2 -shared -o opty.so -fPIC opty.c -DUSE_DOUBLE -I /usr/local/include/csoundforrest@salvage:~/c$ sudo cp opty.so /usr/lib ------------------------------ but that led to error: syntax error, unexpected T_IDENT, expecting T_OPCODE or T_FUNCTION or ',' or '[' (token "opty") from file utes.csd (1) line 16: >>>iresult, kresult opty <<< Unexpected untyped word kresult when expecting a variable whenever the opcode had the line 'allegro_init(); in opty_init -- ---------------------------- but for the call to allegro to work I should have used [Ooops!]: forrest@salvage:~/c$ gcc -O2 -shared -o opty.so -fPIC opty.c -DUSE_DOUBLE -I /usr/local/include/csound -lalleg and that works. -------- Thanks. ---------------------------------------------------------------- ------------------------------------------------- (purpose): [computer 1] ------ [ midi keyboard] (computer 1 runs display & human interface) | | (cable) | [computer 2] (Both computers run csound, one to handle midi & generate algorithmic accompaniment, the other to render the sound.) On Sat, Aug 25, 2018 at 2:52 AM, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote: There is no limitations as to libraries you might use in your plugin code. If you give more details we may be able to help. |
Date | 2018-08-25 17:27 |
From | Victor Lazzarini |
Subject | Re: [Csnd] plugin opcode limitations... |
Sounds good. ======================== Prof. Victor Lazzarini Dean of Arts, Celtic Studies, and Philosophy, Maynooth University, Maynooth, Co Kildare, Ireland Tel: 00 353 7086936 Fax: 00 353 1 7086952 > On 25 Aug 2018, at 17:22, Forrest Curo |
Date | 2018-08-25 22:48 |
From | Forrest Curo |
Subject | Re: [Csnd] plugin opcode limitations... |
Hmm!!! To take an existing program & put it into a plugin opcode [I just tried this with a graphics program of mine]: Rename 'main()' to something else [like 'duhmain()'] . Paste the resulting code into the file before 'typedef struct _youropcode' and call 'duhmain();' within 'youropcode_init' (Do make sure there's a graceful way to exit 'duhmain'!), compile as library & copy into the right directory and where you've put that opcode into csound (inside one always-on instrument is a good place) that program will run until you exit it, then resume csound. Now if that program starts a new pthread, while the other pthread returns to csound... Is it safe to have that pthread change variables in 'youropcode' for 'youropcod_process-control' to use at the next k-cycle? Do we get a sort of inside-out api this way? On Sat, Aug 25, 2018 at 9:27 AM, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote: Sounds good. |
Date | 2018-08-25 23:06 |
From | Victor Lazzarini |
Subject | Re: [Csnd] plugin opcode limitations... |
If you are doing multithreading you will need to be careful with data races. It's not the easiest thing to get right if you have not had
much concurrent programming experience.
In any case, atomic access to variables that
are shared is something you need to use.
Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland
|