For various reasons having to do with microtonal composition, I've put
together a simple MIDI thru processor in Csound. I'm using 5.18.02 (d)  on
Windows 7, running under QuteCsound 0.6.0.

What I'm finding is that Csound seems somehow to be keeping a count of
sustaining notes, and shutting them off if it thinks I'm playing too many.
This behavior is extremely unlikely, but it's what I'm seeing.

Csound is receiving MIDI from my M-Audio Axiom 61, via the Axiom USB driver.
It's transmitting the MIDI output to MIDI Yoke bus 1. My sequencer (which
happens to be FL Studio 10.0.9) is set up to receive only on MIDI Yoke 1, so
all of its MIDI input is coming from Csound by way of MIDI Yoke, not from
the Axiom driver.

Given this minimal alwayson instrument...

instr mThruTest
kstatus, kchan, kdata1, kdata2	midiin
midiout	kstatus, kchan, kdata1, kdata2
endin

...I can press and hold five simultaneous notes on the keyboard, and all of
them will sustain. However, if I press a sixth note while still holding the
first five, notes 1 and 2 will shut off, leaving me with only four
sustaining notes. If I keep adding more sustained notes to the chord using
the keyboard, I will end up with only three sustaining notes, as the earlier
ones will all shut off when new ones start.

The mysterious thing about this -- other than that it can't be happening --
is that I never get stuck notes. Some piece of software, somewhere, is
keeping track of the sustaining notes and shutting off the correct ones
based in the order in which they were played.

If I send MIDI directly from the Axiom to FL Studio, all of my keyboard
notes sustain as expected, so it's clear there's an issue either in Csound
or in MIDI Yoke.

I'll test further, but can anyone tell me, is there any reason why Csound
should cause this phenomenon?



--
View this message in context: http://csound.1045644.n5.nabble.com/MIDI-Thru-Message-Suppression-tp5718720.html
Sent from the Csound - General mailing list archive at Nabble.com.

If you check the messages in the terminal, you will see what Csound is doing. For the first six concomitant notes, you should have six  'new alloc for instr...". If you only have five, then one note is taking the space of another.

I would not expect this as a default behaviour in Csound. It could be programmed, though, but it would need more code.

Victor
On 11 Dec 2012, at 06:09, Jim Aikin  wrote:

> For various reasons having to do with microtonal composition, I've put
> together a simple MIDI thru processor in Csound. I'm using 5.18.02 (d)  on
> Windows 7, running under QuteCsound 0.6.0.
> 
> What I'm finding is that Csound seems somehow to be keeping a count of
> sustaining notes, and shutting them off if it thinks I'm playing too many.
> This behavior is extremely unlikely, but it's what I'm seeing.
> 
> Csound is receiving MIDI from my M-Audio Axiom 61, via the Axiom USB driver.
> It's transmitting the MIDI output to MIDI Yoke bus 1. My sequencer (which
> happens to be FL Studio 10.0.9) is set up to receive only on MIDI Yoke 1, so
> all of its MIDI input is coming from Csound by way of MIDI Yoke, not from
> the Axiom driver.
> 
> Given this minimal alwayson instrument...
> 
> instr mThruTest
> kstatus, kchan, kdata1, kdata2    midiin
> midiout    kstatus, kchan, kdata1, kdata2
> endin
> 
> ...I can press and hold five simultaneous notes on the keyboard, and all of
> them will sustain. However, if I press a sixth note while still holding the
> first five, notes 1 and 2 will shut off, leaving me with only four
> sustaining notes. If I keep adding more sustained notes to the chord using
> the keyboard, I will end up with only three sustaining notes, as the earlier
> ones will all shut off when new ones start.
> 
> The mysterious thing about this -- other than that it can't be happening --
> is that I never get stuck notes. Some piece of software, somewhere, is
> keeping track of the sustaining notes and shutting off the correct ones
> based in the order in which they were played.
> 
> If I send MIDI directly from the Axiom to FL Studio, all of my keyboard
> notes sustain as expected, so it's clear there's an issue either in Csound
> or in MIDI Yoke.
> 
> I'll test further, but can anyone tell me, is there any reason why Csound
> should cause this phenomenon?
> 
> 
> 
> --
> View this message in context: http://csound.1045644.n5.nabble.com/MIDI-Thru-Message-Suppression-tp5718720.html
> Sent from the Csound - General mailing list archive at Nabble.com.
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 

Sorry, I only noticed now that you are using a single always on instrument. Maybe you can add some printk2 to check whar messages are going through.



On 11 Dec 2012, at 07:20, Victor  wrote:

> If you check the messages in the terminal, you will see what Csound is doing. For the first six concomitant notes, you should have six  'new alloc for instr...". If you only have five, then one note is taking the space of another.
> 
> I would not expect this as a default behaviour in Csound. It could be programmed, though, but it would need more code.
> 
> Victor
> On 11 Dec 2012, at 06:09, Jim Aikin  wrote:
> 
>> For various reasons having to do with microtonal composition, I've put
>> together a simple MIDI thru processor in Csound. I'm using 5.18.02 (d)  on
>> Windows 7, running under QuteCsound 0.6.0.
>> 
>> What I'm finding is that Csound seems somehow to be keeping a count of
>> sustaining notes, and shutting them off if it thinks I'm playing too many.
>> This behavior is extremely unlikely, but it's what I'm seeing.
>> 
>> Csound is receiving MIDI from my M-Audio Axiom 61, via the Axiom USB driver.
>> It's transmitting the MIDI output to MIDI Yoke bus 1. My sequencer (which
>> happens to be FL Studio 10.0.9) is set up to receive only on MIDI Yoke 1, so
>> all of its MIDI input is coming from Csound by way of MIDI Yoke, not from
>> the Axiom driver.
>> 
>> Given this minimal alwayson instrument...
>> 
>> instr mThruTest
>> kstatus, kchan, kdata1, kdata2    midiin
>> midiout    kstatus, kchan, kdata1, kdata2
>> endin
>> 
>> ...I can press and hold five simultaneous notes on the keyboard, and all of
>> them will sustain. However, if I press a sixth note while still holding the
>> first five, notes 1 and 2 will shut off, leaving me with only four
>> sustaining notes. If I keep adding more sustained notes to the chord using
>> the keyboard, I will end up with only three sustaining notes, as the earlier
>> ones will all shut off when new ones start.
>> 
>> The mysterious thing about this -- other than that it can't be happening --
>> is that I never get stuck notes. Some piece of software, somewhere, is
>> keeping track of the sustaining notes and shutting off the correct ones
>> based in the order in which they were played.
>> 
>> If I send MIDI directly from the Axiom to FL Studio, all of my keyboard
>> notes sustain as expected, so it's clear there's an issue either in Csound
>> or in MIDI Yoke.
>> 
>> I'll test further, but can anyone tell me, is there any reason why Csound
>> should cause this phenomenon?
>> 
>> 
>> 
>> --
>> View this message in context: http://csound.1045644.n5.nabble.com/MIDI-Thru-Message-Suppression-tp5718720.html
>> Sent from the Csound - General mailing list archive at Nabble.com.
>> 
>> 
>> Send bugs reports to the Sourceforge bug tracker
>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>> 
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 

Unfortunately, the whole thing has now stopped working. I now have a
situation where Csound refuses to run when a sequencer, any sequencer, is
running. Csound complains about portaudio and portmidi errors when I try to
run the .csd. Or conversely, Csound runs, but the sequencer won't send audio
to ASIO4ALL because Csound is doing something even though portaudio is set
to "none," which was not the case in my initial tests, but now the system
has changed, even after I restarted Windows.

To quote Firesign Theatre, "I think I'll go live in a tree and learn to play
the flute."

I'll test further tomorrow. Maybe my system will magically heal itself
overnight.

--JA



--
View this message in context: http://csound.1045644.n5.nabble.com/MIDI-Thru-Message-Suppression-tp5718720p5718723.html
Sent from the Csound - General mailing list archive at Nabble.com.

After further investigation, it seems clear to me that Csound is doing
something undocumented and arguably very wrong with real-time MIDI data. I
edited my simple MIDI thru instrument to add a print statement, like this:

instr 104, mThruTest
kstatus, kchan, kdata1, kdata2	midiin
if (kstatus != 0) then
	printks "Got an event to play!\\n", 0.01
endif
midiout	kstatus, kchan, kdata1, kdata2
endin

At this point, playing one note at a time on the keyboard, pressing and
releasing the key, causes one message to print on key-down and another on
key-up -- as expected.

If I press and hold more and more notes, then I get one message per note-on,
as before. However, I also get a "new alloc for instr mThruTest" on each
note-on. This should not be happening. There should be only one instance of
mThruTest running, because it certainly isn't instr number 1, so it
shouldn't be starting new instances. And when I lift my fingers one by one
from the chord, instead of seeing one print statement per note-off, I see as
many print statements as there are active mThruTest instruments.

The basic problem seems to be that Csound is starting extra instances of the
alwayson instrument, which it shouldn't do, because that instrument is not
numbered between 1 and 16. In addition, Csound is shutting off notes that
have been started by the extra instance of mThruTest according to some
arbitrary note-count criterion of its own ... and without shutting off the
instance.

This is all when the keyboard transmits on MIDI channel 1. When I switch the
keyboard to send on channel 2, Csound gets even more confusificated. I start
getting stuck notes when I lift my fingers -- and they're notes that I
didn't play! I can play, for instance, an E and then a G#, and when the G#
starts, Csound may also play a D. The D won't be ended when I lift my
fingers, of course, as it's a phantom event. It will get stuck. (I'm playing
an organ preset on the softsynth, so as to hear stuck notes and dropped
notes more easily.)

midiin and midiout ought to be simple, transparent objects, but it seems
they're not. The business of extra instances of an alwayson instrument
getting initiated is just as troubling.

Any insights on this weird situation would be more than welcome....

--JA



--
View this message in context: http://csound.1045644.n5.nabble.com/MIDI-Thru-Message-Suppression-tp5718720p5718736.html
Sent from the Csound - General mailing list archive at Nabble.com.

I think I've figured it out. (Pretty sure, in fact.) The problem seems to
arise because Csound is starting instances of instruments in response to
MIDI note-on messages even if the instrument in question is NOT numbered
between 1 and 16.

A .csd that illustrates this is below. I got rid of the call to alwayson in
my previous experiment, using a score line instead to start my instrument
running, but that didn't eliminate the problem. However, "massign 0, 0"
eliminates it. If you comment out the massign line in the .csd, you will
observe that as you add notes to a held chord, you'll keep stacking new
instances of the test instrument -- even though it's numbered 100, not 1.

In fact, the instances will start if you play notes on channel 2 as well. I
haven't checked the other channels.

Each running instance of the instr will then respond as a MIDI thru device,
so the nth note in a held chord sends n note-ons to midiout. And vice-versa;
as you lift your fingers, you'll get n note-offs, then n-1 note-offs, and so
on.

Possibly the parser only sets up the code to do this if it detects a midiin
or other MIDI receive opcode in the instrument; I haven't checked that, but
it's a logical possibility. In any event, I can't think that this is how
Csound is intended to operate. It's quite likely to be a bug.

Note that I'm not using CsOptions or command line flags to activate the MIDI
I/O, because I'm using the Configuration box in QuteCsound.

--JA

*******************






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

massign	0, 0

instr 100, mThruTest
kstatus, kchan, kdata1, kdata2	midiin
if (kstatus != 0) then
	printks, "Got an event to play! kstatus is %i, kdata1 is %i.\\n", 0.01,
kstatus, kdata1
endif
midiout	kstatus, kchan, kdata1, kdata2
endin



i 100	0	3600





--
View this message in context: http://csound.1045644.n5.nabble.com/MIDI-Thru-Message-Suppression-tp5718720p5718738.html
Sent from the Csound - General mailing list archive at Nabble.com.

I think it works like this:

1) if you have 1 instrument only, Csound works on omni(?) mode, ie. it responds to all channels into that single instrument.
2) if you have more than one instrument and instrs 1 - 16 , then by default  instr 1 -> chn 1, instr 2 -> chn 2, unless you alter the mapping
3) if you have more than one instrument, but instr N, 1 <= N <= 16,  is missing, then chn N will be routed by default to the lowest order instrument.

So some scenarios:

a) instr 1 & 100 defined:

chn 1-16 get routed to 1, 100 never gets played from MIDI. This would be the solution for your original case (without using massign).
 
b) instrs 2 - 15 defined.

chns 1 & 16 get played by instr 2, other channels get played by their respective instrument numbers.


Regards

Victor

On 11 Dec 2012, at 23:10, Jim Aikin wrote:

> I think I've figured it out. (Pretty sure, in fact.) The problem seems to
> arise because Csound is starting instances of instruments in response to
> MIDI note-on messages even if the instrument in question is NOT numbered
> between 1 and 16.
> 
> A .csd that illustrates this is below. I got rid of the call to alwayson in
> my previous experiment, using a score line instead to start my instrument
> running, but that didn't eliminate the problem. However, "massign 0, 0"
> eliminates it. If you comment out the massign line in the .csd, you will
> observe that as you add notes to a held chord, you'll keep stacking new
> instances of the test instrument -- even though it's numbered 100, not 1.
> 
> In fact, the instances will start if you play notes on channel 2 as well. I
> haven't checked the other channels.
> 
> Each running instance of the instr will then respond as a MIDI thru device,
> so the nth note in a held chord sends n note-ons to midiout. And vice-versa;
> as you lift your fingers, you'll get n note-offs, then n-1 note-offs, and so
> on.
> 
> Possibly the parser only sets up the code to do this if it detects a midiin
> or other MIDI receive opcode in the instrument; I haven't checked that, but
> it's a logical possibility. In any event, I can't think that this is how
> Csound is intended to operate. It's quite likely to be a bug.
> 
> Note that I'm not using CsOptions or command line flags to activate the MIDI
> I/O, because I'm using the Configuration box in QuteCsound.
> 
> --JA
> 
> *******************
> 
> 
> 
> 
> 
> 
> sr = 44100
> ksmps = 4
> nchnls = 2
> 0dbfs = 1
> 
> massign	0, 0
> 
> instr 100, mThruTest
> kstatus, kchan, kdata1, kdata2	midiin
> if (kstatus != 0) then
> 	printks, "Got an event to play! kstatus is %i, kdata1 is %i.\\n", 0.01,
> kstatus, kdata1
> endif
> midiout	kstatus, kchan, kdata1, kdata2
> endin
> 
> 
> 
> i 100	0	3600
> 
> 
> 
> 
> 
> --
> View this message in context: http://csound.1045644.n5.nabble.com/MIDI-Thru-Message-Suppression-tp5718720p5718738.html
> Sent from the Csound - General mailing list archive at Nabble.com.
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie

victor -

thanks for this detailed information. i did not know this. can it be 
written anywhere in the manual?

best -

	joachim


Am 13.12.2012 10:28, schrieb Victor Lazzarini:
> I think it works like this:
>
> 1) if you have 1 instrument only, Csound works on omni(?) mode, ie. it responds to all channels into that single instrument.
> 2) if you have more than one instrument and instrs 1 - 16 , then by default  instr 1 -> chn 1, instr 2 -> chn 2, unless you alter the mapping
> 3) if you have more than one instrument, but instr N, 1 <= N <= 16,  is missing, then chn N will be routed by default to the lowest order instrument.
>
> So some scenarios:
>
> a) instr 1 & 100 defined:
>
> chn 1-16 get routed to 1, 100 never gets played from MIDI. This would be the solution for your original case (without using massign).
>
> b) instrs 2 - 15 defined.
>
> chns 1 & 16 get played by instr 2, other channels get played by their respective instrument numbers.
>
>
> Regards
>
> Victor
>
> On 11 Dec 2012, at 23:10, Jim Aikin wrote:
>
>> I think I've figured it out. (Pretty sure, in fact.) The problem seems to
>> arise because Csound is starting instances of instruments in response to
>> MIDI note-on messages even if the instrument in question is NOT numbered
>> between 1 and 16.
>>
>> A .csd that illustrates this is below. I got rid of the call to alwayson in
>> my previous experiment, using a score line instead to start my instrument
>> running, but that didn't eliminate the problem. However, "massign 0, 0"
>> eliminates it. If you comment out the massign line in the .csd, you will
>> observe that as you add notes to a held chord, you'll keep stacking new
>> instances of the test instrument -- even though it's numbered 100, not 1.
>>
>> In fact, the instances will start if you play notes on channel 2 as well. I
>> haven't checked the other channels.
>>
>> Each running instance of the instr will then respond as a MIDI thru device,
>> so the nth note in a held chord sends n note-ons to midiout. And vice-versa;
>> as you lift your fingers, you'll get n note-offs, then n-1 note-offs, and so
>> on.
>>
>> Possibly the parser only sets up the code to do this if it detects a midiin
>> or other MIDI receive opcode in the instrument; I haven't checked that, but
>> it's a logical possibility. In any event, I can't think that this is how
>> Csound is intended to operate. It's quite likely to be a bug.
>>
>> Note that I'm not using CsOptions or command line flags to activate the MIDI
>> I/O, because I'm using the Configuration box in QuteCsound.
>>
>> --JA
>>
>> *******************
>>
>> 
>> 
>> 
>> 
>>
>> sr = 44100
>> ksmps = 4
>> nchnls = 2
>> 0dbfs = 1
>>
>> massign	0, 0
>>
>> instr 100, mThruTest
>> kstatus, kchan, kdata1, kdata2	midiin
>> if (kstatus != 0) then
>> 	printks, "Got an event to play! kstatus is %i, kdata1 is %i.\\n", 0.01,
>> kstatus, kdata1
>> endif
>> midiout	kstatus, kchan, kdata1, kdata2
>> endin
>>
>> 
>> 
>> i 100	0	3600
>> 
>> 
>>
>>
>>
>> --
>> View this message in context: http://csound.1045644.n5.nabble.com/MIDI-Thru-Message-Suppression-tp5718720p5718738.html
>> Sent from the Csound - General mailing list archive at Nabble.com.
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>
> Dr Victor Lazzarini
> Senior Lecturer
> Dept. of Music
> NUI Maynooth Ireland
> tel.: +353 1 708 3545
> Victor dot Lazzarini AT nuim dot ie
>
>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>              https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>

yes, I think this could go in the MIDI section.
On 15 Dec 2012, at 11:34, joachim heintz wrote:

> victor -
> 
> thanks for this detailed information. i did not know this. can it be written anywhere in the manual?
> 
> best -
> 
> 	joachim
> 
> 
> Am 13.12.2012 10:28, schrieb Victor Lazzarini:
>> I think it works like this:
>> 
>> 1) if you have 1 instrument only, Csound works on omni(?) mode, ie. it responds to all channels into that single instrument.
>> 2) if you have more than one instrument and instrs 1 - 16 , then by default  instr 1 -> chn 1, instr 2 -> chn 2, unless you alter the mapping
>> 3) if you have more than one instrument, but instr N, 1 <= N <= 16,  is missing, then chn N will be routed by default to the lowest order instrument.
>> 
>> So some scenarios:
>> 
>> a) instr 1 & 100 defined:
>> 
>> chn 1-16 get routed to 1, 100 never gets played from MIDI. This would be the solution for your original case (without using massign).
>> 
>> b) instrs 2 - 15 defined.
>> 
>> chns 1 & 16 get played by instr 2, other channels get played by their respective instrument numbers.
>> 
>> 
>> Regards
>> 
>> Victor
>> 
>> On 11 Dec 2012, at 23:10, Jim Aikin wrote:
>> 
>>> I think I've figured it out. (Pretty sure, in fact.) The problem seems to
>>> arise because Csound is starting instances of instruments in response to
>>> MIDI note-on messages even if the instrument in question is NOT numbered
>>> between 1 and 16.
>>> 
>>> A .csd that illustrates this is below. I got rid of the call to alwayson in
>>> my previous experiment, using a score line instead to start my instrument
>>> running, but that didn't eliminate the problem. However, "massign 0, 0"
>>> eliminates it. If you comment out the massign line in the .csd, you will
>>> observe that as you add notes to a held chord, you'll keep stacking new
>>> instances of the test instrument -- even though it's numbered 100, not 1.
>>> 
>>> In fact, the instances will start if you play notes on channel 2 as well. I
>>> haven't checked the other channels.
>>> 
>>> Each running instance of the instr will then respond as a MIDI thru device,
>>> so the nth note in a held chord sends n note-ons to midiout. And vice-versa;
>>> as you lift your fingers, you'll get n note-offs, then n-1 note-offs, and so
>>> on.
>>> 
>>> Possibly the parser only sets up the code to do this if it detects a midiin
>>> or other MIDI receive opcode in the instrument; I haven't checked that, but
>>> it's a logical possibility. In any event, I can't think that this is how
>>> Csound is intended to operate. It's quite likely to be a bug.
>>> 
>>> Note that I'm not using CsOptions or command line flags to activate the MIDI
>>> I/O, because I'm using the Configuration box in QuteCsound.
>>> 
>>> --JA
>>> 
>>> *******************
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> sr = 44100
>>> ksmps = 4
>>> nchnls = 2
>>> 0dbfs = 1
>>> 
>>> massign	0, 0
>>> 
>>> instr 100, mThruTest
>>> kstatus, kchan, kdata1, kdata2	midiin
>>> if (kstatus != 0) then
>>> 	printks, "Got an event to play! kstatus is %i, kdata1 is %i.\\n", 0.01,
>>> kstatus, kdata1
>>> endif
>>> midiout	kstatus, kchan, kdata1, kdata2
>>> endin
>>> 
>>> 
>>> 
>>> i 100	0	3600
>>> 
>>> 
>>> 
>>> 
>>> 
>>> --
>>> View this message in context: http://csound.1045644.n5.nabble.com/MIDI-Thru-Message-Suppression-tp5718720p5718738.html
>>> Sent from the Csound - General mailing list archive at Nabble.com.
>>> 
>>> 
>>> Send bugs reports to the Sourceforge bug tracker
>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>> 
>> 
>> Dr Victor Lazzarini
>> Senior Lecturer
>> Dept. of Music
>> NUI Maynooth Ireland
>> tel.: +353 1 708 3545
>> Victor dot Lazzarini AT nuim dot ie
>> 
>> 
>> 
>> 
>> 
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>> 
>> 
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie

this would be very helpful. thanks -
	j


Am 15.12.2012 14:56, schrieb Victor Lazzarini:
> yes, I think this could go in the MIDI section.
> On 15 Dec 2012, at 11:34, joachim heintz wrote:
>
>> victor -
>>
>> thanks for this detailed information. i did not know this. can it be written anywhere in the manual?
>>
>> best -
>>
>> 	joachim
>>
>>
>> Am 13.12.2012 10:28, schrieb Victor Lazzarini:
>>> I think it works like this:
>>>
>>> 1) if you have 1 instrument only, Csound works on omni(?) mode, ie. it responds to all channels into that single instrument.
>>> 2) if you have more than one instrument and instrs 1 - 16 , then by default  instr 1 -> chn 1, instr 2 -> chn 2, unless you alter the mapping
>>> 3) if you have more than one instrument, but instr N, 1 <= N <= 16,  is missing, then chn N will be routed by default to the lowest order instrument.
>>>
>>> So some scenarios:
>>>
>>> a) instr 1 & 100 defined:
>>>
>>> chn 1-16 get routed to 1, 100 never gets played from MIDI. This would be the solution for your original case (without using massign).
>>>
>>> b) instrs 2 - 15 defined.
>>>
>>> chns 1 & 16 get played by instr 2, other channels get played by their respective instrument numbers.
>>>
>>>
>>> Regards
>>>
>>> Victor
>>>
>>> On 11 Dec 2012, at 23:10, Jim Aikin wrote:
>>>
>>>> I think I've figured it out. (Pretty sure, in fact.) The problem seems to
>>>> arise because Csound is starting instances of instruments in response to
>>>> MIDI note-on messages even if the instrument in question is NOT numbered
>>>> between 1 and 16.
>>>>
>>>> A .csd that illustrates this is below. I got rid of the call to alwayson in
>>>> my previous experiment, using a score line instead to start my instrument
>>>> running, but that didn't eliminate the problem. However, "massign 0, 0"
>>>> eliminates it. If you comment out the massign line in the .csd, you will
>>>> observe that as you add notes to a held chord, you'll keep stacking new
>>>> instances of the test instrument -- even though it's numbered 100, not 1.
>>>>
>>>> In fact, the instances will start if you play notes on channel 2 as well. I
>>>> haven't checked the other channels.
>>>>
>>>> Each running instance of the instr will then respond as a MIDI thru device,
>>>> so the nth note in a held chord sends n note-ons to midiout. And vice-versa;
>>>> as you lift your fingers, you'll get n note-offs, then n-1 note-offs, and so
>>>> on.
>>>>
>>>> Possibly the parser only sets up the code to do this if it detects a midiin
>>>> or other MIDI receive opcode in the instrument; I haven't checked that, but
>>>> it's a logical possibility. In any event, I can't think that this is how
>>>> Csound is intended to operate. It's quite likely to be a bug.
>>>>
>>>> Note that I'm not using CsOptions or command line flags to activate the MIDI
>>>> I/O, because I'm using the Configuration box in QuteCsound.
>>>>
>>>> --JA
>>>>
>>>> *******************
>>>>
>>>> 
>>>> 
>>>> 
>>>> 
>>>>
>>>> sr = 44100
>>>> ksmps = 4
>>>> nchnls = 2
>>>> 0dbfs = 1
>>>>
>>>> massign	0, 0
>>>>
>>>> instr 100, mThruTest
>>>> kstatus, kchan, kdata1, kdata2	midiin
>>>> if (kstatus != 0) then
>>>> 	printks, "Got an event to play! kstatus is %i, kdata1 is %i.\\n", 0.01,
>>>> kstatus, kdata1
>>>> endif
>>>> midiout	kstatus, kchan, kdata1, kdata2
>>>> endin
>>>>
>>>> 
>>>> 
>>>> i 100	0	3600
>>>> 
>>>> 
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context: http://csound.1045644.n5.nabble.com/MIDI-Thru-Message-Suppression-tp5718720p5718738.html
>>>> Sent from the Csound - General mailing list archive at Nabble.com.
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>
>>>
>>> Dr Victor Lazzarini
>>> Senior Lecturer
>>> Dept. of Music
>>> NUI Maynooth Ireland
>>> tel.: +353 1 708 3545
>>> Victor dot Lazzarini AT nuim dot ie
>>>
>>>
>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>              https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>
>>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>
> Dr Victor Lazzarini
> Senior Lecturer
> Dept. of Music
> NUI Maynooth Ireland
> tel.: +353 1 708 3545
> Victor dot Lazzarini AT nuim dot ie
>
>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>              https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>

information is in midi section, in git





--
View this message in context: http://csound.1045644.n5.nabble.com/MIDI-Thru-Message-Suppression-tp5718720p5719112.html
Sent from the Csound - General mailing list archive at Nabble.com.