Csound Csound-dev Csound-tekno Search About

[Csnd-dev] scheduling events in pluggins

Date2016-03-21 12:33
FromPeter Burgess
Subject[Csnd-dev] scheduling events in pluggins
Gonna stack up one last question...

Trying to schedule an event from my new pluggin, I've stolen bits of
code from schedule.c, and I've included linevent.h in my source, but I
can't figure out what's going on with these functions:

int eventOpcodeI_(CSOUND *csound, LINEVENT *p, int s, char p1);
int eventOpcode_(CSOUND *csound, LINEVENT *p, int s, char p1);

They are declared in schedule.c but never defined. Is that because
they are defined in some of the core Csound source? How can I use
these functions in a pluggin opcode source?

Pete

-- 
http://algorythmradio.com

Date2016-03-21 12:47
FromPeter Burgess
SubjectRe: [Csnd-dev] scheduling events in pluggins
sorry, I meant to say, I got this error message when trying to call
either of the above functions:

WARNING: could not open library
'/usr/local/lib/csound/plugins64-6.0/libalcoGen.so'
(/usr/local/lib/csound/plugins64-6.0/libalcoGen.so: undefined symbol:
_Z13eventOpcodeI_P7CSOUND_P8LINEVENTic)

On Mon, Mar 21, 2016 at 12:33 PM, Peter Burgess
 wrote:
> Gonna stack up one last question...
>
> Trying to schedule an event from my new pluggin, I've stolen bits of
> code from schedule.c, and I've included linevent.h in my source, but I
> can't figure out what's going on with these functions:
>
> int eventOpcodeI_(CSOUND *csound, LINEVENT *p, int s, char p1);
> int eventOpcode_(CSOUND *csound, LINEVENT *p, int s, char p1);
>
> They are declared in schedule.c but never defined. Is that because
> they are defined in some of the core Csound source? How can I use
> these functions in a pluggin opcode source?
>
> Pete
>
> --
> http://algorythmradio.com
> https://soundcloud.com/algorythmradio



-- 
http://algorythmradio.com

Date2016-03-21 12:47
FromSteven Yi
SubjectRe: [Csnd-dev] scheduling events in pluggins
The definitions are in Engine/lineevent.c.  I'm not sure why
schedule.c doesn't have an extern or something along those lines.  I
don't think these are exposed by the API for plugins or hosts to use.

On Mon, Mar 21, 2016 at 8:33 AM, Peter Burgess
 wrote:
> Gonna stack up one last question...
>
> Trying to schedule an event from my new pluggin, I've stolen bits of
> code from schedule.c, and I've included linevent.h in my source, but I
> can't figure out what's going on with these functions:
>
> int eventOpcodeI_(CSOUND *csound, LINEVENT *p, int s, char p1);
> int eventOpcode_(CSOUND *csound, LINEVENT *p, int s, char p1);
>
> They are declared in schedule.c but never defined. Is that because
> they are defined in some of the core Csound source? How can I use
> these functions in a pluggin opcode source?
>
> Pete
>
> --
> http://algorythmradio.com

Date2016-03-21 12:56
FromPeter Burgess
SubjectRe: [Csnd-dev] scheduling events in pluggins
you're right, it is in linevent. I've added linevent.h already. I've
just tried adding extern aswell just in case, but no dice. Is there
another way of doing this? You can send events via the APIs, so there
must be a function somewhere I can access. I might also try just
copying the function from linevent.c and see if that'll work

On Mon, Mar 21, 2016 at 12:47 PM, Steven Yi  wrote:
> The definitions are in Engine/lineevent.c.  I'm not sure why
> schedule.c doesn't have an extern or something along those lines.  I
> don't think these are exposed by the API for plugins or hosts to use.
>
> On Mon, Mar 21, 2016 at 8:33 AM, Peter Burgess
>  wrote:
>> Gonna stack up one last question...
>>
>> Trying to schedule an event from my new pluggin, I've stolen bits of
>> code from schedule.c, and I've included linevent.h in my source, but I
>> can't figure out what's going on with these functions:
>>
>> int eventOpcodeI_(CSOUND *csound, LINEVENT *p, int s, char p1);
>> int eventOpcode_(CSOUND *csound, LINEVENT *p, int s, char p1);
>>
>> They are declared in schedule.c but never defined. Is that because
>> they are defined in some of the core Csound source? How can I use
>> these functions in a pluggin opcode source?
>>
>> Pete
>>
>> --
>> http://algorythmradio.com
>> https://soundcloud.com/algorythmradio



-- 
http://algorythmradio.com

Date2016-03-21 13:06
FromPeter Burgess
SubjectRe: [Csnd-dev] scheduling events in pluggins
nope, copying the function makes things much worse! lol

On Mon, Mar 21, 2016 at 12:56 PM, Peter Burgess
 wrote:
> you're right, it is in linevent. I've added linevent.h already. I've
> just tried adding extern aswell just in case, but no dice. Is there
> another way of doing this? You can send events via the APIs, so there
> must be a function somewhere I can access. I might also try just
> copying the function from linevent.c and see if that'll work
>
> On Mon, Mar 21, 2016 at 12:47 PM, Steven Yi  wrote:
>> The definitions are in Engine/lineevent.c.  I'm not sure why
>> schedule.c doesn't have an extern or something along those lines.  I
>> don't think these are exposed by the API for plugins or hosts to use.
>>
>> On Mon, Mar 21, 2016 at 8:33 AM, Peter Burgess
>>  wrote:
>>> Gonna stack up one last question...
>>>
>>> Trying to schedule an event from my new pluggin, I've stolen bits of
>>> code from schedule.c, and I've included linevent.h in my source, but I
>>> can't figure out what's going on with these functions:
>>>
>>> int eventOpcodeI_(CSOUND *csound, LINEVENT *p, int s, char p1);
>>> int eventOpcode_(CSOUND *csound, LINEVENT *p, int s, char p1);
>>>
>>> They are declared in schedule.c but never defined. Is that because
>>> they are defined in some of the core Csound source? How can I use
>>> these functions in a pluggin opcode source?
>>>
>>> Pete
>>>
>>> --
>>> http://algorythmradio.com
>>> https://soundcloud.com/algorythmradio
>
>
>
> --
> http://algorythmradio.com
> https://soundcloud.com/algorythmradio



-- 
http://algorythmradio.com

Date2016-03-21 13:12
FromPeter Burgess
SubjectRe: [Csnd-dev] scheduling events in pluggins
Adding linevent.c to my project also doesn't seem to be viable as it
includes csoundCore.h, so is the answer actually that I just need to
build it into csound to access this rather than do the pluggin thing?
I feel this will make the process of writing and testing the new
opcode much longer, but I'll try that if it's the best way

On Mon, Mar 21, 2016 at 1:06 PM, Peter Burgess
 wrote:
> nope, copying the function makes things much worse! lol
>
> On Mon, Mar 21, 2016 at 12:56 PM, Peter Burgess
>  wrote:
>> you're right, it is in linevent. I've added linevent.h already. I've
>> just tried adding extern aswell just in case, but no dice. Is there
>> another way of doing this? You can send events via the APIs, so there
>> must be a function somewhere I can access. I might also try just
>> copying the function from linevent.c and see if that'll work
>>
>> On Mon, Mar 21, 2016 at 12:47 PM, Steven Yi  wrote:
>>> The definitions are in Engine/lineevent.c.  I'm not sure why
>>> schedule.c doesn't have an extern or something along those lines.  I
>>> don't think these are exposed by the API for plugins or hosts to use.
>>>
>>> On Mon, Mar 21, 2016 at 8:33 AM, Peter Burgess
>>>  wrote:
>>>> Gonna stack up one last question...
>>>>
>>>> Trying to schedule an event from my new pluggin, I've stolen bits of
>>>> code from schedule.c, and I've included linevent.h in my source, but I
>>>> can't figure out what's going on with these functions:
>>>>
>>>> int eventOpcodeI_(CSOUND *csound, LINEVENT *p, int s, char p1);
>>>> int eventOpcode_(CSOUND *csound, LINEVENT *p, int s, char p1);
>>>>
>>>> They are declared in schedule.c but never defined. Is that because
>>>> they are defined in some of the core Csound source? How can I use
>>>> these functions in a pluggin opcode source?
>>>>
>>>> Pete
>>>>
>>>> --
>>>> http://algorythmradio.com
>>>> https://soundcloud.com/algorythmradio
>>
>>
>>
>> --
>> http://algorythmradio.com
>> https://soundcloud.com/algorythmradio
>
>
>
> --
> http://algorythmradio.com
> https://soundcloud.com/algorythmradio



-- 
http://algorythmradio.com

Date2016-03-21 13:24
FromSteven Yi
SubjectRe: [Csnd-dev] scheduling events in pluggins
These functions are not externally accessible.  You should maybe look
at the score event related functions in API:

    /**
     * Send a new score event. 'type' is the score event type ('a', 'i', 'q',
     * 'f', or 'e').
     * 'numFields' is the size of the pFields array.  'pFields' is an array of
     * floats with all the pfields for this event, starting with the p1 value
     * specified in pFields[0].
     */
    PUBLIC int csoundScoreEvent(CSOUND *,
            char type, const MYFLT *pFields, long numFields);

    /**
     * Like csoundScoreEvent(), this function inserts a score event, but
     * at absolute time with respect to the start of performance, or from an
     * offset set with time_ofs
     */
    PUBLIC int csoundScoreEventAbsolute(CSOUND *,
            char type, const MYFLT *pfields, long numFields, double time_ofs);

    /**
     * Input a NULL-terminated string (as if from a console),
     * used for line events.
     */
    PUBLIC void csoundInputMessage(CSOUND *, const char *message);


If those don't work, it'd be better to figure out what you do need,
and we could all then figure out what's the best API to release for
the feature.


On Mon, Mar 21, 2016 at 9:12 AM, Peter Burgess
 wrote:
> Adding linevent.c to my project also doesn't seem to be viable as it
> includes csoundCore.h, so is the answer actually that I just need to
> build it into csound to access this rather than do the pluggin thing?
> I feel this will make the process of writing and testing the new
> opcode much longer, but I'll try that if it's the best way
>
> On Mon, Mar 21, 2016 at 1:06 PM, Peter Burgess
>  wrote:
>> nope, copying the function makes things much worse! lol
>>
>> On Mon, Mar 21, 2016 at 12:56 PM, Peter Burgess
>>  wrote:
>>> you're right, it is in linevent. I've added linevent.h already. I've
>>> just tried adding extern aswell just in case, but no dice. Is there
>>> another way of doing this? You can send events via the APIs, so there
>>> must be a function somewhere I can access. I might also try just
>>> copying the function from linevent.c and see if that'll work
>>>
>>> On Mon, Mar 21, 2016 at 12:47 PM, Steven Yi  wrote:
>>>> The definitions are in Engine/lineevent.c.  I'm not sure why
>>>> schedule.c doesn't have an extern or something along those lines.  I
>>>> don't think these are exposed by the API for plugins or hosts to use.
>>>>
>>>> On Mon, Mar 21, 2016 at 8:33 AM, Peter Burgess
>>>>  wrote:
>>>>> Gonna stack up one last question...
>>>>>
>>>>> Trying to schedule an event from my new pluggin, I've stolen bits of
>>>>> code from schedule.c, and I've included linevent.h in my source, but I
>>>>> can't figure out what's going on with these functions:
>>>>>
>>>>> int eventOpcodeI_(CSOUND *csound, LINEVENT *p, int s, char p1);
>>>>> int eventOpcode_(CSOUND *csound, LINEVENT *p, int s, char p1);
>>>>>
>>>>> They are declared in schedule.c but never defined. Is that because
>>>>> they are defined in some of the core Csound source? How can I use
>>>>> these functions in a pluggin opcode source?
>>>>>
>>>>> Pete
>>>>>
>>>>> --
>>>>> http://algorythmradio.com
>>>>> https://soundcloud.com/algorythmradio
>>>
>>>
>>>
>>> --
>>> http://algorythmradio.com
>>> https://soundcloud.com/algorythmradio
>>
>>
>>
>> --
>> http://algorythmradio.com
>> https://soundcloud.com/algorythmradio
>
>
>
> --
> http://algorythmradio.com

Date2016-03-21 13:30
FromPeter Burgess
SubjectRe: [Csnd-dev] scheduling events in pluggins
I've had a look through, that looks like it should work out fine. I'll
let you know how it goes

On Mon, Mar 21, 2016 at 1:24 PM, Steven Yi  wrote:
> These functions are not externally accessible.  You should maybe look
> at the score event related functions in API:
>
>     /**
>      * Send a new score event. 'type' is the score event type ('a', 'i', 'q',
>      * 'f', or 'e').
>      * 'numFields' is the size of the pFields array.  'pFields' is an array of
>      * floats with all the pfields for this event, starting with the p1 value
>      * specified in pFields[0].
>      */
>     PUBLIC int csoundScoreEvent(CSOUND *,
>             char type, const MYFLT *pFields, long numFields);
>
>     /**
>      * Like csoundScoreEvent(), this function inserts a score event, but
>      * at absolute time with respect to the start of performance, or from an
>      * offset set with time_ofs
>      */
>     PUBLIC int csoundScoreEventAbsolute(CSOUND *,
>             char type, const MYFLT *pfields, long numFields, double time_ofs);
>
>     /**
>      * Input a NULL-terminated string (as if from a console),
>      * used for line events.
>      */
>     PUBLIC void csoundInputMessage(CSOUND *, const char *message);
>
>
> If those don't work, it'd be better to figure out what you do need,
> and we could all then figure out what's the best API to release for
> the feature.
>
>
> On Mon, Mar 21, 2016 at 9:12 AM, Peter Burgess
>  wrote:
>> Adding linevent.c to my project also doesn't seem to be viable as it
>> includes csoundCore.h, so is the answer actually that I just need to
>> build it into csound to access this rather than do the pluggin thing?
>> I feel this will make the process of writing and testing the new
>> opcode much longer, but I'll try that if it's the best way
>>
>> On Mon, Mar 21, 2016 at 1:06 PM, Peter Burgess
>>  wrote:
>>> nope, copying the function makes things much worse! lol
>>>
>>> On Mon, Mar 21, 2016 at 12:56 PM, Peter Burgess
>>>  wrote:
>>>> you're right, it is in linevent. I've added linevent.h already. I've
>>>> just tried adding extern aswell just in case, but no dice. Is there
>>>> another way of doing this? You can send events via the APIs, so there
>>>> must be a function somewhere I can access. I might also try just
>>>> copying the function from linevent.c and see if that'll work
>>>>
>>>> On Mon, Mar 21, 2016 at 12:47 PM, Steven Yi  wrote:
>>>>> The definitions are in Engine/lineevent.c.  I'm not sure why
>>>>> schedule.c doesn't have an extern or something along those lines.  I
>>>>> don't think these are exposed by the API for plugins or hosts to use.
>>>>>
>>>>> On Mon, Mar 21, 2016 at 8:33 AM, Peter Burgess
>>>>>  wrote:
>>>>>> Gonna stack up one last question...
>>>>>>
>>>>>> Trying to schedule an event from my new pluggin, I've stolen bits of
>>>>>> code from schedule.c, and I've included linevent.h in my source, but I
>>>>>> can't figure out what's going on with these functions:
>>>>>>
>>>>>> int eventOpcodeI_(CSOUND *csound, LINEVENT *p, int s, char p1);
>>>>>> int eventOpcode_(CSOUND *csound, LINEVENT *p, int s, char p1);
>>>>>>
>>>>>> They are declared in schedule.c but never defined. Is that because
>>>>>> they are defined in some of the core Csound source? How can I use
>>>>>> these functions in a pluggin opcode source?
>>>>>>
>>>>>> Pete
>>>>>>
>>>>>> --
>>>>>> http://algorythmradio.com
>>>>>> https://soundcloud.com/algorythmradio
>>>>
>>>>
>>>>
>>>> --
>>>> http://algorythmradio.com
>>>> https://soundcloud.com/algorythmradio
>>>
>>>
>>>
>>> --
>>> http://algorythmradio.com
>>> https://soundcloud.com/algorythmradio
>>
>>
>>
>> --
>> http://algorythmradio.com
>> https://soundcloud.com/algorythmradio



-- 
http://algorythmradio.com

Date2016-03-21 13:52
FromPeter Burgess
SubjectRe: [Csnd-dev] scheduling events in pluggins
for some reason my project is telling me that csoundScoreEvent() is
undeclared. I've definitely got csound.h included, and an include path
set to a copy of csound.h. I've also tried changing which csound.h the
include path pointed to, as I just noticed it was pointing to an old
copy (I've only organised where csound source lives, and still need to
purge some old versions).

Unfortunately, when I set the include path to the most recent source,
I get a load of errors that I didn't get before, with or without
csoundScoreEvent() and the inclusion of csound.h. Something to do with
interlocks.h. I should probably report this problem in a separate
thread I guess, as it definitely wasn't happening with the old copy.

That second issue aside, the old copy of csound.h definately contains
the function, so I'm not sure why it's telling me it's undeclared.

On Mon, Mar 21, 2016 at 1:30 PM, Peter Burgess
 wrote:
> I've had a look through, that looks like it should work out fine. I'll
> let you know how it goes
>
> On Mon, Mar 21, 2016 at 1:24 PM, Steven Yi  wrote:
>> These functions are not externally accessible.  You should maybe look
>> at the score event related functions in API:
>>
>>     /**
>>      * Send a new score event. 'type' is the score event type ('a', 'i', 'q',
>>      * 'f', or 'e').
>>      * 'numFields' is the size of the pFields array.  'pFields' is an array of
>>      * floats with all the pfields for this event, starting with the p1 value
>>      * specified in pFields[0].
>>      */
>>     PUBLIC int csoundScoreEvent(CSOUND *,
>>             char type, const MYFLT *pFields, long numFields);
>>
>>     /**
>>      * Like csoundScoreEvent(), this function inserts a score event, but
>>      * at absolute time with respect to the start of performance, or from an
>>      * offset set with time_ofs
>>      */
>>     PUBLIC int csoundScoreEventAbsolute(CSOUND *,
>>             char type, const MYFLT *pfields, long numFields, double time_ofs);
>>
>>     /**
>>      * Input a NULL-terminated string (as if from a console),
>>      * used for line events.
>>      */
>>     PUBLIC void csoundInputMessage(CSOUND *, const char *message);
>>
>>
>> If those don't work, it'd be better to figure out what you do need,
>> and we could all then figure out what's the best API to release for
>> the feature.
>>
>>
>> On Mon, Mar 21, 2016 at 9:12 AM, Peter Burgess
>>  wrote:
>>> Adding linevent.c to my project also doesn't seem to be viable as it
>>> includes csoundCore.h, so is the answer actually that I just need to
>>> build it into csound to access this rather than do the pluggin thing?
>>> I feel this will make the process of writing and testing the new
>>> opcode much longer, but I'll try that if it's the best way
>>>
>>> On Mon, Mar 21, 2016 at 1:06 PM, Peter Burgess
>>>  wrote:
>>>> nope, copying the function makes things much worse! lol
>>>>
>>>> On Mon, Mar 21, 2016 at 12:56 PM, Peter Burgess
>>>>  wrote:
>>>>> you're right, it is in linevent. I've added linevent.h already. I've
>>>>> just tried adding extern aswell just in case, but no dice. Is there
>>>>> another way of doing this? You can send events via the APIs, so there
>>>>> must be a function somewhere I can access. I might also try just
>>>>> copying the function from linevent.c and see if that'll work
>>>>>
>>>>> On Mon, Mar 21, 2016 at 12:47 PM, Steven Yi  wrote:
>>>>>> The definitions are in Engine/lineevent.c.  I'm not sure why
>>>>>> schedule.c doesn't have an extern or something along those lines.  I
>>>>>> don't think these are exposed by the API for plugins or hosts to use.
>>>>>>
>>>>>> On Mon, Mar 21, 2016 at 8:33 AM, Peter Burgess
>>>>>>  wrote:
>>>>>>> Gonna stack up one last question...
>>>>>>>
>>>>>>> Trying to schedule an event from my new pluggin, I've stolen bits of
>>>>>>> code from schedule.c, and I've included linevent.h in my source, but I
>>>>>>> can't figure out what's going on with these functions:
>>>>>>>
>>>>>>> int eventOpcodeI_(CSOUND *csound, LINEVENT *p, int s, char p1);
>>>>>>> int eventOpcode_(CSOUND *csound, LINEVENT *p, int s, char p1);
>>>>>>>
>>>>>>> They are declared in schedule.c but never defined. Is that because
>>>>>>> they are defined in some of the core Csound source? How can I use
>>>>>>> these functions in a pluggin opcode source?
>>>>>>>
>>>>>>> Pete
>>>>>>>
>>>>>>> --
>>>>>>> http://algorythmradio.com
>>>>>>> https://soundcloud.com/algorythmradio
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> http://algorythmradio.com
>>>>> https://soundcloud.com/algorythmradio
>>>>
>>>>
>>>>
>>>> --
>>>> http://algorythmradio.com
>>>> https://soundcloud.com/algorythmradio
>>>
>>>
>>>
>>> --
>>> http://algorythmradio.com
>>> https://soundcloud.com/algorythmradio
>
>
>
> --
> http://algorythmradio.com
> https://soundcloud.com/algorythmradio



-- 
http://algorythmradio.com

Date2016-03-21 14:37
FromSteven Yi
SubjectRe: [Csnd-dev] scheduling events in pluggins
Sorry, for opcodes you should dereference the function from the CSOUND
struct.  It looks like these are available:

    int (*insert_score_event)(CSOUND *, EVTBLK *, double);
    int (*insert_score_event_at_sample)(CSOUND *, EVTBLK *, int64_t);
    void (*InputMessage)(CSOUND *, const char *message__);



On Mon, Mar 21, 2016 at 9:52 AM, Peter Burgess
 wrote:
> for some reason my project is telling me that csoundScoreEvent() is
> undeclared. I've definitely got csound.h included, and an include path
> set to a copy of csound.h. I've also tried changing which csound.h the
> include path pointed to, as I just noticed it was pointing to an old
> copy (I've only organised where csound source lives, and still need to
> purge some old versions).
>
> Unfortunately, when I set the include path to the most recent source,
> I get a load of errors that I didn't get before, with or without
> csoundScoreEvent() and the inclusion of csound.h. Something to do with
> interlocks.h. I should probably report this problem in a separate
> thread I guess, as it definitely wasn't happening with the old copy.
>
> That second issue aside, the old copy of csound.h definately contains
> the function, so I'm not sure why it's telling me it's undeclared.
>
> On Mon, Mar 21, 2016 at 1:30 PM, Peter Burgess
>  wrote:
>> I've had a look through, that looks like it should work out fine. I'll
>> let you know how it goes
>>
>> On Mon, Mar 21, 2016 at 1:24 PM, Steven Yi  wrote:
>>> These functions are not externally accessible.  You should maybe look
>>> at the score event related functions in API:
>>>
>>>     /**
>>>      * Send a new score event. 'type' is the score event type ('a', 'i', 'q',
>>>      * 'f', or 'e').
>>>      * 'numFields' is the size of the pFields array.  'pFields' is an array of
>>>      * floats with all the pfields for this event, starting with the p1 value
>>>      * specified in pFields[0].
>>>      */
>>>     PUBLIC int csoundScoreEvent(CSOUND *,
>>>             char type, const MYFLT *pFields, long numFields);
>>>
>>>     /**
>>>      * Like csoundScoreEvent(), this function inserts a score event, but
>>>      * at absolute time with respect to the start of performance, or from an
>>>      * offset set with time_ofs
>>>      */
>>>     PUBLIC int csoundScoreEventAbsolute(CSOUND *,
>>>             char type, const MYFLT *pfields, long numFields, double time_ofs);
>>>
>>>     /**
>>>      * Input a NULL-terminated string (as if from a console),
>>>      * used for line events.
>>>      */
>>>     PUBLIC void csoundInputMessage(CSOUND *, const char *message);
>>>
>>>
>>> If those don't work, it'd be better to figure out what you do need,
>>> and we could all then figure out what's the best API to release for
>>> the feature.
>>>
>>>
>>> On Mon, Mar 21, 2016 at 9:12 AM, Peter Burgess
>>>  wrote:
>>>> Adding linevent.c to my project also doesn't seem to be viable as it
>>>> includes csoundCore.h, so is the answer actually that I just need to
>>>> build it into csound to access this rather than do the pluggin thing?
>>>> I feel this will make the process of writing and testing the new
>>>> opcode much longer, but I'll try that if it's the best way
>>>>
>>>> On Mon, Mar 21, 2016 at 1:06 PM, Peter Burgess
>>>>  wrote:
>>>>> nope, copying the function makes things much worse! lol
>>>>>
>>>>> On Mon, Mar 21, 2016 at 12:56 PM, Peter Burgess
>>>>>  wrote:
>>>>>> you're right, it is in linevent. I've added linevent.h already. I've
>>>>>> just tried adding extern aswell just in case, but no dice. Is there
>>>>>> another way of doing this? You can send events via the APIs, so there
>>>>>> must be a function somewhere I can access. I might also try just
>>>>>> copying the function from linevent.c and see if that'll work
>>>>>>
>>>>>> On Mon, Mar 21, 2016 at 12:47 PM, Steven Yi  wrote:
>>>>>>> The definitions are in Engine/lineevent.c.  I'm not sure why
>>>>>>> schedule.c doesn't have an extern or something along those lines.  I
>>>>>>> don't think these are exposed by the API for plugins or hosts to use.
>>>>>>>
>>>>>>> On Mon, Mar 21, 2016 at 8:33 AM, Peter Burgess
>>>>>>>  wrote:
>>>>>>>> Gonna stack up one last question...
>>>>>>>>
>>>>>>>> Trying to schedule an event from my new pluggin, I've stolen bits of
>>>>>>>> code from schedule.c, and I've included linevent.h in my source, but I
>>>>>>>> can't figure out what's going on with these functions:
>>>>>>>>
>>>>>>>> int eventOpcodeI_(CSOUND *csound, LINEVENT *p, int s, char p1);
>>>>>>>> int eventOpcode_(CSOUND *csound, LINEVENT *p, int s, char p1);
>>>>>>>>
>>>>>>>> They are declared in schedule.c but never defined. Is that because
>>>>>>>> they are defined in some of the core Csound source? How can I use
>>>>>>>> these functions in a pluggin opcode source?
>>>>>>>>
>>>>>>>> Pete
>>>>>>>>
>>>>>>>> --
>>>>>>>> http://algorythmradio.com
>>>>>>>> https://soundcloud.com/algorythmradio
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> http://algorythmradio.com
>>>>>> https://soundcloud.com/algorythmradio
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> http://algorythmradio.com
>>>>> https://soundcloud.com/algorythmradio
>>>>
>>>>
>>>>
>>>> --
>>>> http://algorythmradio.com
>>>> https://soundcloud.com/algorythmradio
>>
>>
>>
>> --
>> http://algorythmradio.com
>> https://soundcloud.com/algorythmradio
>
>
>
> --
> http://algorythmradio.com

Date2016-03-21 20:29
FromPeter Burgess
SubjectRe: [Csnd-dev] scheduling events in pluggins
Aha, cheers! I'll give that a try tomororw :D

Date2016-03-22 11:04
FromPeter Burgess
SubjectRe: [Csnd-dev] scheduling events in pluggins
That's working! I'm using csound->insert_score_event(), and it's
working great :D

I have one question regarding the members of EVTBLK though. It has an
array to store the parameters in, ie instr number, start time,
duration etc...  but it also has these members:

/** Event start time */ MYFLT p2orig;
/** Length */ MYFLT p3orig;

As far as I can tell, they don't seem to represent the start time and
length of the event I'm creating. Do I need to worry about these
parameters?

On Mon, Mar 21, 2016 at 8:29 PM, Peter Burgess
 wrote:
> Aha, cheers! I'll give that a try tomororw :D



-- 
http://algorythmradio.com

Date2016-03-22 13:16
FromPeter Burgess
SubjectRe: [Csnd-dev] scheduling events in pluggins
Oh, one more thing, In my opcode, what's the best way of acquiring the
p2 of the calling instrument without passing p2 as a parameter to the
opcode? I'm guessing CSOUND has a member somewhere that'll tell me,
but I'm struggling to find it

On Tue, Mar 22, 2016 at 11:04 AM, Peter Burgess
 wrote:
> That's working! I'm using csound->insert_score_event(), and it's
> working great :D
>
> I have one question regarding the members of EVTBLK though. It has an
> array to store the parameters in, ie instr number, start time,
> duration etc...  but it also has these members:
>
> /** Event start time */ MYFLT p2orig;
> /** Length */ MYFLT p3orig;
>
> As far as I can tell, they don't seem to represent the start time and
> length of the event I'm creating. Do I need to worry about these
> parameters?
>
> On Mon, Mar 21, 2016 at 8:29 PM, Peter Burgess
>  wrote:
>> Aha, cheers! I'll give that a try tomororw :D
>
>
>
> --
> http://algorythmradio.com
> https://soundcloud.com/algorythmradio



-- 
http://algorythmradio.com

Date2016-03-22 13:45
FromSteven Yi
SubjectRe: [Csnd-dev] scheduling events in pluggins
I'm not sure about the EVTBLK values; perhaps Victor or John or
someone else could chime in?  If you don't hear a reply in a couple
days, just ping again here and I should have time to research it.

For p2, I think you can go to the OPDS header of the opcode, then from
there look for the INSDS header for the instrument, which should have
the pfield values. (At least, I think that is the case, as I'm working
from memory here...)

On Tue, Mar 22, 2016 at 9:16 AM, Peter Burgess
 wrote:
> Oh, one more thing, In my opcode, what's the best way of acquiring the
> p2 of the calling instrument without passing p2 as a parameter to the
> opcode? I'm guessing CSOUND has a member somewhere that'll tell me,
> but I'm struggling to find it
>
> On Tue, Mar 22, 2016 at 11:04 AM, Peter Burgess
>  wrote:
>> That's working! I'm using csound->insert_score_event(), and it's
>> working great :D
>>
>> I have one question regarding the members of EVTBLK though. It has an
>> array to store the parameters in, ie instr number, start time,
>> duration etc...  but it also has these members:
>>
>> /** Event start time */ MYFLT p2orig;
>> /** Length */ MYFLT p3orig;
>>
>> As far as I can tell, they don't seem to represent the start time and
>> length of the event I'm creating. Do I need to worry about these
>> parameters?
>>
>> On Mon, Mar 21, 2016 at 8:29 PM, Peter Burgess
>>  wrote:
>>> Aha, cheers! I'll give that a try tomororw :D
>>
>>
>>
>> --
>> http://algorythmradio.com
>> https://soundcloud.com/algorythmradio
>
>
>
> --
> http://algorythmradio.com

Date2016-03-22 13:47
FromPeter Burgess
SubjectRe: [Csnd-dev] scheduling events in pluggins
Cool thanks! I'll check that out :D

On Tue, Mar 22, 2016 at 1:45 PM, Steven Yi  wrote:
> I'm not sure about the EVTBLK values; perhaps Victor or John or
> someone else could chime in?  If you don't hear a reply in a couple
> days, just ping again here and I should have time to research it.
>
> For p2, I think you can go to the OPDS header of the opcode, then from
> there look for the INSDS header for the instrument, which should have
> the pfield values. (At least, I think that is the case, as I'm working
> from memory here...)
>
> On Tue, Mar 22, 2016 at 9:16 AM, Peter Burgess
>  wrote:
>> Oh, one more thing, In my opcode, what's the best way of acquiring the
>> p2 of the calling instrument without passing p2 as a parameter to the
>> opcode? I'm guessing CSOUND has a member somewhere that'll tell me,
>> but I'm struggling to find it
>>
>> On Tue, Mar 22, 2016 at 11:04 AM, Peter Burgess
>>  wrote:
>>> That's working! I'm using csound->insert_score_event(), and it's
>>> working great :D
>>>
>>> I have one question regarding the members of EVTBLK though. It has an
>>> array to store the parameters in, ie instr number, start time,
>>> duration etc...  but it also has these members:
>>>
>>> /** Event start time */ MYFLT p2orig;
>>> /** Length */ MYFLT p3orig;
>>>
>>> As far as I can tell, they don't seem to represent the start time and
>>> length of the event I'm creating. Do I need to worry about these
>>> parameters?
>>>
>>> On Mon, Mar 21, 2016 at 8:29 PM, Peter Burgess
>>>  wrote:
>>>> Aha, cheers! I'll give that a try tomororw :D
>>>
>>>
>>>
>>> --
>>> http://algorythmradio.com
>>> https://soundcloud.com/algorythmradio
>>
>>
>>
>> --
>> http://algorythmradio.com
>> https://soundcloud.com/algorythmradio



-- 
http://algorythmradio.com

Date2016-03-22 14:12
Fromjpff
SubjectRe: [Csnd-dev] scheduling events in pluggins
nt tested but I suspect
 		csound->curip->p2.value

On Tue, 22 Mar 2016, Steven Yi wrote:

> I'm not sure about the EVTBLK values; perhaps Victor or John or
> someone else could chime in?  If you don't hear a reply in a couple
> days, just ping again here and I should have time to research it.
>
> For p2, I think you can go to the OPDS header of the opcode, then from
> there look for the INSDS header for the instrument, which should have
> the pfield values. (At least, I think that is the case, as I'm working
> from memory here...)
>
> On Tue, Mar 22, 2016 at 9:16 AM, Peter Burgess
>  wrote:
>> Oh, one more thing, In my opcode, what's the best way of acquiring the
>> p2 of the calling instrument without passing p2 as a parameter to the
>> opcode? I'm guessing CSOUND has a member somewhere that'll tell me,
>> but I'm struggling to find it
>>
>> On Tue, Mar 22, 2016 at 11:04 AM, Peter Burgess
>>  wrote:
>>> That's working! I'm using csound->insert_score_event(), and it's
>>> working great :D
>>>
>>> I have one question regarding the members of EVTBLK though. It has an
>>> array to store the parameters in, ie instr number, start time,
>>> duration etc...  but it also has these members:
>>>
>>> /** Event start time */ MYFLT p2orig;
>>> /** Length */ MYFLT p3orig;
>>>
>>> As far as I can tell, they don't seem to represent the start time and
>>> length of the event I'm creating. Do I need to worry about these
>>> parameters?
>>>
>>> On Mon, Mar 21, 2016 at 8:29 PM, Peter Burgess
>>>  wrote:
>>>> Aha, cheers! I'll give that a try tomororw :D
>>>
>>>
>>>
>>> --
>>> http://algorythmradio.com
>>> https://soundcloud.com/algorythmradio
>>
>>
>>
>> --
>> http://algorythmradio.com
>> https://soundcloud.com/algorythmradio

Date2016-03-22 14:29
FromSteven Yi
SubjectRe: [Csnd-dev] scheduling events in pluggins

That may work buy would be bad for parallel processing. (We need to get rid of curip sometime...)


On Tue, Mar 22, 2016, 10:12 AM jpff <jpff@codemist.co.uk> wrote:
nt tested but I suspect
                csound->curip->p2.value

On Tue, 22 Mar 2016, Steven Yi wrote:

> I'm not sure about the EVTBLK values; perhaps Victor or John or
> someone else could chime in?  If you don't hear a reply in a couple
> days, just ping again here and I should have time to research it.
>
> For p2, I think you can go to the OPDS header of the opcode, then from
> there look for the INSDS header for the instrument, which should have
> the pfield values. (At least, I think that is the case, as I'm working
> from memory here...)
>
> On Tue, Mar 22, 2016 at 9:16 AM, Peter Burgess
> <pete.soundtechnician@gmail.com> wrote:
>> Oh, one more thing, In my opcode, what's the best way of acquiring the
>> p2 of the calling instrument without passing p2 as a parameter to the
>> opcode? I'm guessing CSOUND has a member somewhere that'll tell me,
>> but I'm struggling to find it
>>
>> On Tue, Mar 22, 2016 at 11:04 AM, Peter Burgess
>> <pete.soundtechnician@gmail.com> wrote:
>>> That's working! I'm using csound->insert_score_event(), and it's
>>> working great :D
>>>
>>> I have one question regarding the members of EVTBLK though. It has an
>>> array to store the parameters in, ie instr number, start time,
>>> duration etc...  but it also has these members:
>>>
>>> /** Event start time */ MYFLT p2orig;
>>> /** Length */ MYFLT p3orig;
>>>
>>> As far as I can tell, they don't seem to represent the start time and
>>> length of the event I'm creating. Do I need to worry about these
>>> parameters?
>>>
>>> On Mon, Mar 21, 2016 at 8:29 PM, Peter Burgess
>>> <pete.soundtechnician@gmail.com> wrote:
>>>> Aha, cheers! I'll give that a try tomororw :D
>>>
>>>
>>>
>>> --
>>> http://algorythmradio.com
>>> https://soundcloud.com/algorythmradio
>>
>>
>>
>> --
>> http://algorythmradio.com
>> https://soundcloud.com/algorythmradio
>

Date2016-03-22 15:43
FromPeter Burgess
SubjectRe: [Csnd-dev] scheduling events in pluggins
it seems I can't access the member curip anyway. The only header it
seems to appear in is csoundCore.h, and including that doesn't seem to
allow me access. I guess that might be unavailable to plug-ins as
well?

That aside, I have come across another curious issue. I am currently
passing the p2 of the instrument as an argument until I can find a
better solution, and my opcode works just fine unless I use a repeat
segment in the score, then the p2 resets with every repeat cycle, and
I don't hear my scheduled events any more, presumably because they're
being inserted in the past. How should I deal with that? I've had a
look through the sources again to see if I can find any answers there,
but there's nothin obvious.

Cheers for the help thus far guys! Much appreciated

On Tue, Mar 22, 2016 at 2:29 PM, Steven Yi  wrote:
> That may work buy would be bad for parallel processing. (We need to get rid
> of curip sometime...)
>
>
> On Tue, Mar 22, 2016, 10:12 AM jpff  wrote:
>>
>> nt tested but I suspect
>>                 csound->curip->p2.value
>>
>> On Tue, 22 Mar 2016, Steven Yi wrote:
>>
>> > I'm not sure about the EVTBLK values; perhaps Victor or John or
>> > someone else could chime in?  If you don't hear a reply in a couple
>> > days, just ping again here and I should have time to research it.
>> >
>> > For p2, I think you can go to the OPDS header of the opcode, then from
>> > there look for the INSDS header for the instrument, which should have
>> > the pfield values. (At least, I think that is the case, as I'm working
>> > from memory here...)
>> >
>> > On Tue, Mar 22, 2016 at 9:16 AM, Peter Burgess
>> >  wrote:
>> >> Oh, one more thing, In my opcode, what's the best way of acquiring the
>> >> p2 of the calling instrument without passing p2 as a parameter to the
>> >> opcode? I'm guessing CSOUND has a member somewhere that'll tell me,
>> >> but I'm struggling to find it
>> >>
>> >> On Tue, Mar 22, 2016 at 11:04 AM, Peter Burgess
>> >>  wrote:
>> >>> That's working! I'm using csound->insert_score_event(), and it's
>> >>> working great :D
>> >>>
>> >>> I have one question regarding the members of EVTBLK though. It has an
>> >>> array to store the parameters in, ie instr number, start time,
>> >>> duration etc...  but it also has these members:
>> >>>
>> >>> /** Event start time */ MYFLT p2orig;
>> >>> /** Length */ MYFLT p3orig;
>> >>>
>> >>> As far as I can tell, they don't seem to represent the start time and
>> >>> length of the event I'm creating. Do I need to worry about these
>> >>> parameters?
>> >>>
>> >>> On Mon, Mar 21, 2016 at 8:29 PM, Peter Burgess
>> >>>  wrote:
>> >>>> Aha, cheers! I'll give that a try tomororw :D
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> http://algorythmradio.com
>> >>> https://soundcloud.com/algorythmradio
>> >>
>> >>
>> >>
>> >> --
>> >> http://algorythmradio.com
>> >> https://soundcloud.com/algorythmradio
>> >



-- 
http://algorythmradio.com