I'm trying to decide on a strategy for implementing some voice leading
features with midi input. In a simple case, monophonic voice
allocation with selectable "last note priority" or "first note
priority" like on some older analog synths. Another example might be
handling the top note differently (e.g. playing another instrument, or
using other parameters) for polyphonic playing.

One way of doing it would be to disable normal midi assignment
(massign), and just using midiin and the event opcode to start and
stop other instruments. But I wonder if this might give a slower
response than just using the normal midi handling with massign (due to
the k-rate processing of midi data and subsequent k-rate processing of
the event opcode). Also, it seems logical that with midiin I can only
process one single midi event per k-rate pass, and then I might get a
delay if several events appear at the midi input simultaneously. Do I
understand this correctly ?

Another way, if I use a separate instrument that is triggered via midi
the normal way (let's say instrument 1, and using massign 1,1). This
instrument does not produce any sound, but handles voice leading
features and starts another instrument via the event opcode. Would it
be faster to use event_i than event ? And, even if I use event_i, will
I get a delay of one k-cycle with this method ?

best
Oeyvind

Hi,

On Wed, Apr 15, 2009 at 1:52 PM, Oeyvind Brandtsegg  wrote:

> One way of doing it would be to disable normal midi assignment
> (massign), and just using midiin and the event opcode to start and
> stop other instruments. But I wonder if this might give a slower
> response than just using the normal midi handling with massign (due to
> the k-rate processing of midi data and subsequent k-rate processing of
> the event opcode). Also, it seems logical that with midiin I can only
> process one single midi event per k-rate pass, and then I might get a
> delay if several events appear at the midi input simultaneously. Do I
> understand this correctly ?

Yes, but you can use if/kgoto to repeat the midiin opcode in the same
k-pass while there are midi events remaining in the queue.

> Another way, if I use a separate instrument that is triggered via midi
> the normal way (let's say instrument 1, and using massign 1,1). This
> instrument does not produce any sound, but handles voice leading
> features and starts another instrument via the event opcode. Would it
> be faster to use event_i than event ? And, even if I use event_i, will
> I get a delay of one k-cycle with this method ?
>

I'm not sure but I think you would be 1 k-cycle late. The best way to
manage this is doing it within th triggered instrument with
conditionals and global variables.

Cheers,
Andrés

Thanks Andres,
The tip on creating a loop around midiin is very useful.

I've given the event/event_i question some more thought, and I wonder
if the following is correct:

method1;
massign 1,2
instr 2 produces sound

method2:
massign 1,1
instr1 starts instr2 by using event_i
instr2 produces sound

If event_i does it's job at i-time, then instr 2 will be initialized
before Csound proceed with the first k-cycle of instr 1,
so there should be no difference in timing between method 1 and method 2 above.
Isn't that so?

Oeyvind

2009/4/17 Andres Cabrera :
> Hi,
>
> On Wed, Apr 15, 2009 at 1:52 PM, Oeyvind Brandtsegg  wrote:
>
>> One way of doing it would be to disable normal midi assignment
>> (massign), and just using midiin and the event opcode to start and
>> stop other instruments. But I wonder if this might give a slower
>> response than just using the normal midi handling with massign (due to
>> the k-rate processing of midi data and subsequent k-rate processing of
>> the event opcode). Also, it seems logical that with midiin I can only
>> process one single midi event per k-rate pass, and then I might get a
>> delay if several events appear at the midi input simultaneously. Do I
>> understand this correctly ?
>
> Yes, but you can use if/kgoto to repeat the midiin opcode in the same
> k-pass while there are midi events remaining in the queue.
>
>> Another way, if I use a separate instrument that is triggered via midi
>> the normal way (let's say instrument 1, and using massign 1,1). This
>> instrument does not produce any sound, but handles voice leading
>> features and starts another instrument via the event opcode. Would it
>> be faster to use event_i than event ? And, even if I use event_i, will
>> I get a delay of one k-cycle with this method ?
>>
>
> I'm not sure but I think you would be 1 k-cycle late. The best way to
> manage this is doing it within th triggered instrument with
> conditionals and global variables.
>
> Cheers,
> Andrés
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Hi,

I just tested this and the event is queued on the same k-period. I
find it odd that even the csd below produces it in the first k-period.
Can anyone explain? I would expect that since instr 10 calls instr 2,
the noe would actually be triggered on the next k-period...






sr = 44100
ksmps = 128
nchnls = 2
0dbfs = 1

instr 2
asig oscils 0.5, 440, 0
outs asig, asig
endin

instr 10
event_i "i", 2, 0, 2
endin



i 10 0 5
e



Cheers,
Andrés

On Fri, Apr 17, 2009 at 2:08 AM, Oeyvind Brandtsegg  wrote:
> Thanks Andres,
> The tip on creating a loop around midiin is very useful.
>
> I've given the event/event_i question some more thought, and I wonder
> if the following is correct:
>
> method1;
> massign 1,2
> instr 2 produces sound
>
> method2:
> massign 1,1
> instr1 starts instr2 by using event_i
> instr2 produces sound
>
> If event_i does it's job at i-time, then instr 2 will be initialized
> before Csound proceed with the first k-cycle of instr 1,
> so there should be no difference in timing between method 1 and method 2 above.
> Isn't that so?
>
> Oeyvind
>
> 2009/4/17 Andres Cabrera :
>> Hi,
>>
>> On Wed, Apr 15, 2009 at 1:52 PM, Oeyvind Brandtsegg  wrote:
>>
>>> One way of doing it would be to disable normal midi assignment
>>> (massign), and just using midiin and the event opcode to start and
>>> stop other instruments. But I wonder if this might give a slower
>>> response than just using the normal midi handling with massign (due to
>>> the k-rate processing of midi data and subsequent k-rate processing of
>>> the event opcode). Also, it seems logical that with midiin I can only
>>> process one single midi event per k-rate pass, and then I might get a
>>> delay if several events appear at the midi input simultaneously. Do I
>>> understand this correctly ?
>>
>> Yes, but you can use if/kgoto to repeat the midiin opcode in the same
>> k-pass while there are midi events remaining in the queue.
>>
>>> Another way, if I use a separate instrument that is triggered via midi
>>> the normal way (let's say instrument 1, and using massign 1,1). This
>>> instrument does not produce any sound, but handles voice leading
>>> features and starts another instrument via the event opcode. Would it
>>> be faster to use event_i than event ? And, even if I use event_i, will
>>> I get a delay of one k-cycle with this method ?
>>>
>>
>> I'm not sure but I think you would be 1 k-cycle late. The best way to
>> manage this is doing it within th triggered instrument with
>> conditionals and global variables.
>>
>> Cheers,
>> Andrés
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"



-- 


Andrés

Thanks for checking it out, Andres.
Could it be because Csound processes all init time calls in one go,
and that instr 2 is instantiated in the same i-pass as instr 10, even
though it is instantiated *after* instr 10 ?
I would guess that the order of processing is again correct when it
comes to the k-rate pass of each instrument (first instr 2 k-pass,
then instr 10 k-pass).

More comments appreciated
Oeyvind

2009/4/17 Andres Cabrera :
> Hi,
>
> I just tested this and the event is queued on the same k-period. I
> find it odd that even the csd below produces it in the first k-period.
> Can anyone explain? I would expect that since instr 10 calls instr 2,
> the noe would actually be triggered on the next k-period...
>
> 
> 
> 
> 
>
> sr = 44100
> ksmps = 128
> nchnls = 2
> 0dbfs = 1
>
> instr 2
> asig oscils 0.5, 440, 0
> outs asig, asig
> endin
>
> instr 10
> event_i "i", 2, 0, 2
> endin
>
> 
> 
> i 10 0 5
> e
> 
> 
>
> Cheers,
> Andrés
>
> On Fri, Apr 17, 2009 at 2:08 AM, Oeyvind Brandtsegg  wrote:
>> Thanks Andres,
>> The tip on creating a loop around midiin is very useful.
>>
>> I've given the event/event_i question some more thought, and I wonder
>> if the following is correct:
>>
>> method1;
>> massign 1,2
>> instr 2 produces sound
>>
>> method2:
>> massign 1,1
>> instr1 starts instr2 by using event_i
>> instr2 produces sound
>>
>> If event_i does it's job at i-time, then instr 2 will be initialized
>> before Csound proceed with the first k-cycle of instr 1,
>> so there should be no difference in timing between method 1 and method 2 above.
>> Isn't that so?
>>
>> Oeyvind
>>
>> 2009/4/17 Andres Cabrera :
>>> Hi,
>>>
>>> On Wed, Apr 15, 2009 at 1:52 PM, Oeyvind Brandtsegg  wrote:
>>>
>>>> One way of doing it would be to disable normal midi assignment
>>>> (massign), and just using midiin and the event opcode to start and
>>>> stop other instruments. But I wonder if this might give a slower
>>>> response than just using the normal midi handling with massign (due to
>>>> the k-rate processing of midi data and subsequent k-rate processing of
>>>> the event opcode). Also, it seems logical that with midiin I can only
>>>> process one single midi event per k-rate pass, and then I might get a
>>>> delay if several events appear at the midi input simultaneously. Do I
>>>> understand this correctly ?
>>>
>>> Yes, but you can use if/kgoto to repeat the midiin opcode in the same
>>> k-pass while there are midi events remaining in the queue.
>>>
>>>> Another way, if I use a separate instrument that is triggered via midi
>>>> the normal way (let's say instrument 1, and using massign 1,1). This
>>>> instrument does not produce any sound, but handles voice leading
>>>> features and starts another instrument via the event opcode. Would it
>>>> be faster to use event_i than event ? And, even if I use event_i, will
>>>> I get a delay of one k-cycle with this method ?
>>>>
>>>
>>> I'm not sure but I think you would be 1 k-cycle late. The best way to
>>> manage this is doing it within th triggered instrument with
>>> conditionals and global variables.
>>>
>>> Cheers,
>>> Andrés
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>
>
> --
>
>
> Andrés
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

I think you are totally right. If you try event instead of event_i,  
you have the delay of one k-pass:





sr = 44100
ksmps = 44100
nchnls = 2
0dbfs = 1
instr 1
endin
instr 2
asig oscils 0.5, 440, 0
outs asig, asig
endin
instr 10
event "i", 2, 0, 2; try event_i instead
endin


i 1 0 5
i 10 0 .5
e



I'm very interested in your explorations about the midi handling,  
Oeyvind. I formerly worked with midiin and had often some problems  
with hanging notes, obviously because a note-off message wasn't  
received properly. Keep us informed about your experiences. Best -
	joachim



Am 17.04.2009 um 15:22 schrieb Oeyvind Brandtsegg:

> Thanks for checking it out, Andres.
> Could it be because Csound processes all init time calls in one go,
> and that instr 2 is instantiated in the same i-pass as instr 10, even
> though it is instantiated *after* instr 10 ?
> I would guess that the order of processing is again correct when it
> comes to the k-rate pass of each instrument (first instr 2 k-pass,
> then instr 10 k-pass).
>
> More comments appreciated
> Oeyvind
>
> 2009/4/17 Andres Cabrera :
>> Hi,
>>
>> I just tested this and the event is queued on the same k-period. I
>> find it odd that even the csd below produces it in the first k- 
>> period.
>> Can anyone explain? I would expect that since instr 10 calls instr 2,
>> the noe would actually be triggered on the next k-period...
>>
>> 
>> 
>> 
>> 
>>
>> sr = 44100
>> ksmps = 128
>> nchnls = 2
>> 0dbfs = 1
>>
>> instr 2
>> asig oscils 0.5, 440, 0
>> outs asig, asig
>> endin
>>
>> instr 10
>> event_i "i", 2, 0, 2
>> endin
>>
>> 
>> 
>> i 10 0 5
>> e
>> 
>> 
>>
>> Cheers,
>> Andrés
>>
>> On Fri, Apr 17, 2009 at 2:08 AM, Oeyvind Brandtsegg > > wrote:
>>> Thanks Andres,
>>> The tip on creating a loop around midiin is very useful.
>>>
>>> I've given the event/event_i question some more thought, and I  
>>> wonder
>>> if the following is correct:
>>>
>>> method1;
>>> massign 1,2
>>> instr 2 produces sound
>>>
>>> method2:
>>> massign 1,1
>>> instr1 starts instr2 by using event_i
>>> instr2 produces sound
>>>
>>> If event_i does it's job at i-time, then instr 2 will be initialized
>>> before Csound proceed with the first k-cycle of instr 1,
>>> so there should be no difference in timing between method 1 and  
>>> method 2 above.
>>> Isn't that so?
>>>
>>> Oeyvind
>>>
>>> 2009/4/17 Andres Cabrera :
>>>> Hi,
>>>>
>>>> On Wed, Apr 15, 2009 at 1:52 PM, Oeyvind Brandtsegg >>> > wrote:
>>>>
>>>>> One way of doing it would be to disable normal midi assignment
>>>>> (massign), and just using midiin and the event opcode to start and
>>>>> stop other instruments. But I wonder if this might give a slower
>>>>> response than just using the normal midi handling with massign  
>>>>> (due to
>>>>> the k-rate processing of midi data and subsequent k-rate  
>>>>> processing of
>>>>> the event opcode). Also, it seems logical that with midiin I can  
>>>>> only
>>>>> process one single midi event per k-rate pass, and then I might  
>>>>> get a
>>>>> delay if several events appear at the midi input simultaneously.  
>>>>> Do I
>>>>> understand this correctly ?
>>>>
>>>> Yes, but you can use if/kgoto to repeat the midiin opcode in the  
>>>> same
>>>> k-pass while there are midi events remaining in the queue.
>>>>
>>>>> Another way, if I use a separate instrument that is triggered  
>>>>> via midi
>>>>> the normal way (let's say instrument 1, and using massign 1,1).  
>>>>> This
>>>>> instrument does not produce any sound, but handles voice leading
>>>>> features and starts another instrument via the event opcode.  
>>>>> Would it
>>>>> be faster to use event_i than event ? And, even if I use  
>>>>> event_i, will
>>>>> I get a delay of one k-cycle with this method ?
>>>>>
>>>>
>>>> I'm not sure but I think you would be 1 k-cycle late. The best  
>>>> way to
>>>> manage this is doing it within th triggered instrument with
>>>> conditionals and global variables.
>>>>
>>>> Cheers,
>>>> Andrés
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>>> "unsubscribe csound"
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>> "unsubscribe csound"
>>
>>
>>
>> --
>>
>>
>> Andrés
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe csound"
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"

Thanks for checking it out Joachim.

I've been tempted by the midiin method because of the flexibility it
could provide, but also turned off by the prospect of totally
rewriting the voice handling by bypassing Csound's own handling of
event generation. Currently I'm investigating the method of using
event_i and event (for release segments). For me, it seems simpler to
call a separate instrument to generate the release stage envelopes
than to fiddle around with reinitialization issues (those always
clutters up my thinking and I spend hours just staring at the code not
being able to figure out why it does not work as expected... ;-)

I will share the code as soon as I have something useable

all best
Oeyvind

2009/4/18 joachim heintz :
> I think you are totally right. If you try event instead of event_i, you have
> the delay of one k-pass:
>
> 
> 
> 
> 
> sr = 44100
> ksmps = 44100
> nchnls = 2
> 0dbfs = 1
> instr 1
> endin
> instr 2
> asig oscils 0.5, 440, 0
> outs asig, asig
> endin
> instr 10
> event "i", 2, 0, 2; try event_i instead
> endin
> 
> 
> i 1 0 5
> i 10 0 .5
> e
> 
> 
>
> I'm very interested in your explorations about the midi handling, Oeyvind. I
> formerly worked with midiin and had often some problems with hanging notes,
> obviously because a note-off message wasn't received properly. Keep us
> informed about your experiences. Best -
>        joachim
>
>
>
> Am 17.04.2009 um 15:22 schrieb Oeyvind Brandtsegg:
>
>> Thanks for checking it out, Andres.
>> Could it be because Csound processes all init time calls in one go,
>> and that instr 2 is instantiated in the same i-pass as instr 10, even
>> though it is instantiated *after* instr 10 ?
>> I would guess that the order of processing is again correct when it
>> comes to the k-rate pass of each instrument (first instr 2 k-pass,
>> then instr 10 k-pass).
>>
>> More comments appreciated
>> Oeyvind
>>
>> 2009/4/17 Andres Cabrera :
>>>
>>> Hi,
>>>
>>> I just tested this and the event is queued on the same k-period. I
>>> find it odd that even the csd below produces it in the first k-period.
>>> Can anyone explain? I would expect that since instr 10 calls instr 2,
>>> the noe would actually be triggered on the next k-period...
>>>
>>> 
>>> 
>>> 
>>> 
>>>
>>> sr = 44100
>>> ksmps = 128
>>> nchnls = 2
>>> 0dbfs = 1
>>>
>>> instr 2
>>> asig oscils 0.5, 440, 0
>>> outs asig, asig
>>> endin
>>>
>>> instr 10
>>> event_i "i", 2, 0, 2
>>> endin
>>>
>>> 
>>> 
>>> i 10 0 5
>>> e
>>> 
>>> 
>>>
>>> Cheers,
>>> Andrés
>>>
>>> On Fri, Apr 17, 2009 at 2:08 AM, Oeyvind Brandtsegg 
>>> wrote:
>>>>
>>>> Thanks Andres,
>>>> The tip on creating a loop around midiin is very useful.
>>>>
>>>> I've given the event/event_i question some more thought, and I wonder
>>>> if the following is correct:
>>>>
>>>> method1;
>>>> massign 1,2
>>>> instr 2 produces sound
>>>>
>>>> method2:
>>>> massign 1,1
>>>> instr1 starts instr2 by using event_i
>>>> instr2 produces sound
>>>>
>>>> If event_i does it's job at i-time, then instr 2 will be initialized
>>>> before Csound proceed with the first k-cycle of instr 1,
>>>> so there should be no difference in timing between method 1 and method 2
>>>> above.
>>>> Isn't that so?
>>>>
>>>> Oeyvind
>>>>
>>>> 2009/4/17 Andres Cabrera :
>>>>>
>>>>> Hi,
>>>>>
>>>>> On Wed, Apr 15, 2009 at 1:52 PM, Oeyvind Brandtsegg
>>>>>  wrote:
>>>>>
>>>>>> One way of doing it would be to disable normal midi assignment
>>>>>> (massign), and just using midiin and the event opcode to start and
>>>>>> stop other instruments. But I wonder if this might give a slower
>>>>>> response than just using the normal midi handling with massign (due to
>>>>>> the k-rate processing of midi data and subsequent k-rate processing of
>>>>>> the event opcode). Also, it seems logical that with midiin I can only
>>>>>> process one single midi event per k-rate pass, and then I might get a
>>>>>> delay if several events appear at the midi input simultaneously. Do I
>>>>>> understand this correctly ?
>>>>>
>>>>> Yes, but you can use if/kgoto to repeat the midiin opcode in the same
>>>>> k-pass while there are midi events remaining in the queue.
>>>>>
>>>>>> Another way, if I use a separate instrument that is triggered via midi
>>>>>> the normal way (let's say instrument 1, and using massign 1,1). This
>>>>>> instrument does not produce any sound, but handles voice leading
>>>>>> features and starts another instrument via the event opcode. Would it
>>>>>> be faster to use event_i than event ? And, even if I use event_i, will
>>>>>> I get a delay of one k-cycle with this method ?
>>>>>>
>>>>>
>>>>> I'm not sure but I think you would be 1 k-cycle late. The best way to
>>>>> manage this is doing it within th triggered instrument with
>>>>> conditionals and global variables.
>>>>>
>>>>> Cheers,
>>>>> Andrés
>>>>>
>>>>>
>>>>> Send bugs reports to this list.
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>>> "unsubscribe csound"
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>
>>>
>>>
>>> --
>>>
>>>
>>> Andrés
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"