Whenever I press a midi controller button with the instrument
presented below I get two print outs:

Status:176 Value:127 ChanNo:2 CtrlNo:19
Status:0 Value:127 ChanNo:2 CtrlNo:19

As you can see Csound picks up the first midi message which is a
control change with status byte set 176. Then it sends another message
straight after with a status byte value of 0. As far as I was aware
the smallest number a status byte could be is 128? Anyway this second
message makes it a little annoying to use buttons to start
instruments. Consider the following code, instrument 1 gets called
twice even though I only press the button once.

k1 ctrl7 1, 7, 0, 127
kgo changed k1
if(kgo==1) then
event "i", 1, 0, 10
endif

Instead I must use the midiin opcode and do a lot more checking. Is
this second message there for a reason? If not could it be disabled so
pressing a button once sends one message and not two. If it is needed
can someone explain to me why?

Rory.

//=============simple midi monitor==================
instr 1
kstatus, kchan, kdata1, kdata2 midiin
kupdated changed kstatus, kchan, kdata1, kdata2
if(kupdated==1) then
	printks "Status:%d Value:%d ChanNo:%d CtrlNo:%d\n", 0, kstatus,
kdata2, kchan, kdata1
endif
endin


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"

On 19 Apr 2010, at 01:02, Rory Walsh wrote:

> Whenever I press a midi controller button with the instrument
> presented below I get two print outs:
>
> Status:176 Value:127 ChanNo:2 CtrlNo:19
> Status:0 Value:127 ChanNo:2 CtrlNo:19
>
> As you can see Csound picks up the first midi message which is a
> control change with status byte set 176. Then it sends another message
> straight after with a status byte value of 0. As far as I was aware
> the smallest number a status byte could be is 128? Anyway this second
> message makes it a little annoying to use buttons to start
> instruments. Consider the following code, instrument 1 gets called
> twice even though I only press the button once.
>
> k1 ctrl7 1, 7, 0, 127
> kgo changed k1
> if(kgo==1) then
> event "i", 1, 0, 10
> endif

Why not this?

k1 ctrl7 1, 7, 0, 127
if(k1>0) then
event "i", 1, 0, 10
endif

>
> Instead I must use the midiin opcode and do a lot more checking. Is
> this second message there for a reason? If not could it be disabled so
> pressing a button once sends one message and not two. If it is needed
> can someone explain to me why?
>
> Rory.
>
> //=============simple midi monitor==================
> instr 1
> kstatus, kchan, kdata1, kdata2 midiin
> kupdated changed kstatus, kchan, kdata1, kdata2
> if(kupdated==1) then
> 	printks "Status:%d Value:%d ChanNo:%d CtrlNo:%d\n", 0, kstatus,
> kdata2, kchan, kdata1
> endif
> endin
>
>
> 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"

Thanks Peiman, that provides a solution to this particular problem but
I'm still curious to know why this status byte of 0 is being sent at
all. Other audio/midi applications don't seem to pick it up. Pd, which
uses the portmidi library too, only reports one message per button
push. I'd assume that most end users would expect one message per
button press. I guess someone might be able to provide a good
explanation as to whether this status byte of 0 can prove useful in
certain situations..

Rory.


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"

Hi Rory,

I took a look at Csounds's pmidi.c and PD's s_midi_pm.c file. I am not
sure about the 2nd message with status 0, but it looks like pmidi.c
reports the full status byte. Checking against the MIDI spec:

http://www.midi.org/techspecs/midimessages.php

You'll see that the data bytes in midi start with 0, while the status
byte starts with 1.  My guess from you getting 176 is that you did a
control change message on channel 0.  The status byte would have come
in then as:

10110000

which is 176 in base 10.  The status is usually broken into two parts,
the first and second 4 bits. The first 4 bits will give 8 different
types of messages.  The first 7 types 1000xxxx through 1101 are the
common ones like note-off, note-on, etc.  The 8th one that starts with
1111xxxx are for the system messages. In the common messages, the
second 4 bits denote channel that the message was given on.  If you
use your controller and change the channel it's on, you should get
values reported from 176-92 for status).

I haven't looked at ctrl7, but I imagine it's going to be only passing
on messages with 1011xxxx.  The only use for status byte I'd imagine
is for stripping off the top 4 bits and using the remaining ones to
figure out what channel the message was sent on.  You could probably
that by using:

kchannel = kstatus - 176

That's my interpretation of it at least! :)

As for the 2nd message reported with a status of 0, that seems like it
has to be a bug somewhere. (Haven't seen where though yet, will
continue looking in a moment)

steven


On Sun, Apr 18, 2010 at 9:29 PM, Rory Walsh  wrote:
> Thanks Peiman, that provides a solution to this particular problem but
> I'm still curious to know why this status byte of 0 is being sent at
> all. Other audio/midi applications don't seem to pick it up. Pd, which
> uses the portmidi library too, only reports one message per button
> push. I'd assume that most end users would expect one message per
> button press. I guess someone might be able to provide a good
> explanation as to whether this status byte of 0 can prove useful in
> certain situations..
>
> Rory.
>
>
> 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"

Oh, disregard my comments on ctrl7, I went back and saw that you were
using midiin to read the raw midi input stream.  The midiin opcode has
this code:

      *p->status = (MYFLT) (*temp & (unsigned char) 0xf0);
      *p->chan   = (MYFLT) ((*temp & 0x0f) + 1);

So status is stripping off the bottom 4 bits, but it is not doing any
bitshifting.  I guess depending on point of view, it may be easier or
harder to use it like that.  Most code I think will probably strip the
top bit and bit shift right by 4 to make the status in the range of
0-7 (you can also do (kstatus - 128) / 16).

Eh, or you could do like me and read the manual too late:

http://csounds.com/manual/html/midiin.html

:P

steven

On Sun, Apr 18, 2010 at 11:38 PM, Steven Yi  wrote:
> Hi Rory,
>
> I took a look at Csounds's pmidi.c and PD's s_midi_pm.c file. I am not
> sure about the 2nd message with status 0, but it looks like pmidi.c
> reports the full status byte. Checking against the MIDI spec:
>
> http://www.midi.org/techspecs/midimessages.php
>
> You'll see that the data bytes in midi start with 0, while the status
> byte starts with 1.  My guess from you getting 176 is that you did a
> control change message on channel 0.  The status byte would have come
> in then as:
>
> 10110000
>
> which is 176 in base 10.  The status is usually broken into two parts,
> the first and second 4 bits. The first 4 bits will give 8 different
> types of messages.  The first 7 types 1000xxxx through 1101 are the
> common ones like note-off, note-on, etc.  The 8th one that starts with
> 1111xxxx are for the system messages. In the common messages, the
> second 4 bits denote channel that the message was given on.  If you
> use your controller and change the channel it's on, you should get
> values reported from 176-92 for status).
>
> I haven't looked at ctrl7, but I imagine it's going to be only passing
> on messages with 1011xxxx.  The only use for status byte I'd imagine
> is for stripping off the top 4 bits and using the remaining ones to
> figure out what channel the message was sent on.  You could probably
> that by using:
>
> kchannel = kstatus - 176
>
> That's my interpretation of it at least! :)
>
> As for the 2nd message reported with a status of 0, that seems like it
> has to be a bug somewhere. (Haven't seen where though yet, will
> continue looking in a moment)
>
> steven
>
>
> On Sun, Apr 18, 2010 at 9:29 PM, Rory Walsh  wrote:
>> Thanks Peiman, that provides a solution to this particular problem but
>> I'm still curious to know why this status byte of 0 is being sent at
>> all. Other audio/midi applications don't seem to pick it up. Pd, which
>> uses the portmidi library too, only reports one message per button
>> push. I'd assume that most end users would expect one message per
>> button press. I guess someone might be able to provide a good
>> explanation as to whether this status byte of 0 can prove useful in
>> certain situations..
>>
>> Rory.
>>
>>
>> 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"

Hi Rory,

Could you try the project using one of the other midi drivers (winmm,
alsa, jack)?  Maybe it's a bug with our pmidi.c driver.

steven

On Sun, Apr 18, 2010 at 9:29 PM, Rory Walsh  wrote:
> Thanks Peiman, that provides a solution to this particular problem but
> I'm still curious to know why this status byte of 0 is being sent at
> all. Other audio/midi applications don't seem to pick it up. Pd, which
> uses the portmidi library too, only reports one message per button
> push. I'd assume that most end users would expect one message per
> button press. I guess someone might be able to provide a good
> explanation as to whether this status byte of 0 can prove useful in
> certain situations..
>
> Rory.
>
>
> 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"

Also, just found this page which has a nice explanation with diagrams
of status bytes and MIDI data:

http://www.planetoftunes.com/sequence/statdata.html

Which also reminds me that it should be impossible to have a status of
0, so it's certainly weird.  Do you have a complete CSD you can post
here?  I'd like to take a look to see about reproducing here and
digging in a bit.

Thanks!
steven

On Mon, Apr 19, 2010 at 12:00 AM, Steven Yi  wrote:
> Hi Rory,
>
> Could you try the project using one of the other midi drivers (winmm,
> alsa, jack)?  Maybe it's a bug with our pmidi.c driver.
>
> steven
>
> On Sun, Apr 18, 2010 at 9:29 PM, Rory Walsh  wrote:
>> Thanks Peiman, that provides a solution to this particular problem but
>> I'm still curious to know why this status byte of 0 is being sent at
>> all. Other audio/midi applications don't seem to pick it up. Pd, which
>> uses the portmidi library too, only reports one message per button
>> push. I'd assume that most end users would expect one message per
>> button press. I guess someone might be able to provide a good
>> explanation as to whether this status byte of 0 can prove useful in
>> certain situations..
>>
>> Rory.
>>
>>
>> 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"

I haven't tested this in a while, but I seem to recall that midiin
reports the midi status byte in kstatus when it receives a midi input
message, and kstatus is zero when there is no midi messages in the
input queue. This way of handling status messages internally makes
sense as it is convenient to do conditional processing when kstatus is
zero at all times except whene there is a message.
But ctrl7 should normally just output the controller value, and the
output should stay at this value until a new midi message arrives.
Additionally, ctrl7 should never output anything in the case that the
status myte of an incoming midi message is zero (and indeed the status
byte should actually never be zero if the sender conforms to the
standard midi spec).

Some midi controllers that have buttons can be configured to send a
message only when the button is pushed (momentary), and optionally, a
different message when it is pushed and when it is released (toggle).

Oeyvind

2010/4/19 Steven Yi :
> Also, just found this page which has a nice explanation with diagrams
> of status bytes and MIDI data:
>
> http://www.planetoftunes.com/sequence/statdata.html
>
> Which also reminds me that it should be impossible to have a status of
> 0, so it's certainly weird.  Do you have a complete CSD you can post
> here?  I'd like to take a look to see about reproducing here and
> digging in a bit.
>
> Thanks!
> steven
>
> On Mon, Apr 19, 2010 at 12:00 AM, Steven Yi  wrote:
>> Hi Rory,
>>
>> Could you try the project using one of the other midi drivers (winmm,
>> alsa, jack)?  Maybe it's a bug with our pmidi.c driver.
>>
>> steven
>>
>> On Sun, Apr 18, 2010 at 9:29 PM, Rory Walsh  wrote:
>>> Thanks Peiman, that provides a solution to this particular problem but
>>> I'm still curious to know why this status byte of 0 is being sent at
>>> all. Other audio/midi applications don't seem to pick it up. Pd, which
>>> uses the portmidi library too, only reports one message per button
>>> push. I'd assume that most end users would expect one message per
>>> button press. I guess someone might be able to provide a good
>>> explanation as to whether this status byte of 0 can prove useful in
>>> certain situations..
>>>
>>> Rory.
>>>
>>>
>>> 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"
>
>


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"

To follow up on Steven's request I get the same results when using
winmm. Oeyvind is probably right, it's fine for midiin to report two
messages but it's perhaps not great for ctrl7 to do so?

On 19 April 2010 08:56, Oeyvind Brandtsegg  wrote:
> I haven't tested this in a while, but I seem to recall that midiin
> reports the midi status byte in kstatus when it receives a midi input
> message, and kstatus is zero when there is no midi messages in the
> input queue. This way of handling status messages internally makes
> sense as it is convenient to do conditional processing when kstatus is
> zero at all times except whene there is a message.
> But ctrl7 should normally just output the controller value, and the
> output should stay at this value until a new midi message arrives.
> Additionally, ctrl7 should never output anything in the case that the
> status myte of an incoming midi message is zero (and indeed the status
> byte should actually never be zero if the sender conforms to the
> standard midi spec).
>
> Some midi controllers that have buttons can be configured to send a
> message only when the button is pushed (momentary), and optionally, a
> different message when it is pushed and when it is released (toggle).
>
> Oeyvind
>
> 2010/4/19 Steven Yi :
>> Also, just found this page which has a nice explanation with diagrams
>> of status bytes and MIDI data:
>>
>> http://www.planetoftunes.com/sequence/statdata.html
>>
>> Which also reminds me that it should be impossible to have a status of
>> 0, so it's certainly weird.  Do you have a complete CSD you can post
>> here?  I'd like to take a look to see about reproducing here and
>> digging in a bit.
>>
>> Thanks!
>> steven
>>
>> On Mon, Apr 19, 2010 at 12:00 AM, Steven Yi  wrote:
>>> Hi Rory,
>>>
>>> Could you try the project using one of the other midi drivers (winmm,
>>> alsa, jack)?  Maybe it's a bug with our pmidi.c driver.
>>>
>>> steven
>>>
>>> On Sun, Apr 18, 2010 at 9:29 PM, Rory Walsh  wrote:
>>>> Thanks Peiman, that provides a solution to this particular problem but
>>>> I'm still curious to know why this status byte of 0 is being sent at
>>>> all. Other audio/midi applications don't seem to pick it up. Pd, which
>>>> uses the portmidi library too, only reports one message per button
>>>> push. I'd assume that most end users would expect one message per
>>>> button press. I guess someone might be able to provide a good
>>>> explanation as to whether this status byte of 0 can prove useful in
>>>> certain situations..
>>>>
>>>> Rory.
>>>>
>>>>
>>>> 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"
>>
>>
>
>
> 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"

Just tested this quickly.
As far as I can see it ctrl7 output only changes once when it receives
the appropriate midi controller message, there is nothing wrong when I
test it here.
The event call in the code snippet you provided will then be called
once, not twice in response to a button push on the physical midi
controller, unless the button actually sends a value on release
(toggle mode)

k1 ctrl7 1, 7, 0, 127
kgo changed k1
if(kgo==1) then
event "i", 1, 0, 10
endif


best
Oeyvind


2010/4/19 Rory Walsh :
> To follow up on Steven's request I get the same results when using
> winmm. Oeyvind is probably right, it's fine for midiin to report two
> messages but it's perhaps not great for ctrl7 to do so?
>
> On 19 April 2010 08:56, Oeyvind Brandtsegg  wrote:
>> I haven't tested this in a while, but I seem to recall that midiin
>> reports the midi status byte in kstatus when it receives a midi input
>> message, and kstatus is zero when there is no midi messages in the
>> input queue. This way of handling status messages internally makes
>> sense as it is convenient to do conditional processing when kstatus is
>> zero at all times except whene there is a message.
>> But ctrl7 should normally just output the controller value, and the
>> output should stay at this value until a new midi message arrives.
>> Additionally, ctrl7 should never output anything in the case that the
>> status myte of an incoming midi message is zero (and indeed the status
>> byte should actually never be zero if the sender conforms to the
>> standard midi spec).
>>
>> Some midi controllers that have buttons can be configured to send a
>> message only when the button is pushed (momentary), and optionally, a
>> different message when it is pushed and when it is released (toggle).
>>
>> Oeyvind
>>
>> 2010/4/19 Steven Yi :
>>> Also, just found this page which has a nice explanation with diagrams
>>> of status bytes and MIDI data:
>>>
>>> http://www.planetoftunes.com/sequence/statdata.html
>>>
>>> Which also reminds me that it should be impossible to have a status of
>>> 0, so it's certainly weird.  Do you have a complete CSD you can post
>>> here?  I'd like to take a look to see about reproducing here and
>>> digging in a bit.
>>>
>>> Thanks!
>>> steven
>>>
>>> On Mon, Apr 19, 2010 at 12:00 AM, Steven Yi  wrote:
>>>> Hi Rory,
>>>>
>>>> Could you try the project using one of the other midi drivers (winmm,
>>>> alsa, jack)?  Maybe it's a bug with our pmidi.c driver.
>>>>
>>>> steven
>>>>
>>>> On Sun, Apr 18, 2010 at 9:29 PM, Rory Walsh  wrote:
>>>>> Thanks Peiman, that provides a solution to this particular problem but
>>>>> I'm still curious to know why this status byte of 0 is being sent at
>>>>> all. Other audio/midi applications don't seem to pick it up. Pd, which
>>>>> uses the portmidi library too, only reports one message per button
>>>>> push. I'd assume that most end users would expect one message per
>>>>> button press. I guess someone might be able to provide a good
>>>>> explanation as to whether this status byte of 0 can prove useful in
>>>>> certain situations..
>>>>>
>>>>> Rory.
>>>>>
>>>>>
>>>>> 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"
>>>
>>>
>>
>>
>> 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"
>
>


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"

Thanks Oeyvind. Turns out the midi controller I tested with is sending
toggle messages and what's even more silly is that I never noticed
that instr 1 was being triggered by default every time a message is
received on channel one. Thanks to everyone for taking a look. All is
well now in the world, apart from the cloud of volcanic ash hanging
over us! What a difference a nights sleep makes!

On 19 April 2010 10:15, Oeyvind Brandtsegg  wrote:
> Just tested this quickly.
> As far as I can see it ctrl7 output only changes once when it receives
> the appropriate midi controller message, there is nothing wrong when I
> test it here.
> The event call in the code snippet you provided will then be called
> once, not twice in response to a button push on the physical midi
> controller, unless the button actually sends a value on release
> (toggle mode)
>
> k1 ctrl7 1, 7, 0, 127
> kgo changed k1
> if(kgo==1) then
> event "i", 1, 0, 10
> endif
>
>
> best
> Oeyvind
>
>
> 2010/4/19 Rory Walsh :
>> To follow up on Steven's request I get the same results when using
>> winmm. Oeyvind is probably right, it's fine for midiin to report two
>> messages but it's perhaps not great for ctrl7 to do so?
>>
>> On 19 April 2010 08:56, Oeyvind Brandtsegg  wrote:
>>> I haven't tested this in a while, but I seem to recall that midiin
>>> reports the midi status byte in kstatus when it receives a midi input
>>> message, and kstatus is zero when there is no midi messages in the
>>> input queue. This way of handling status messages internally makes
>>> sense as it is convenient to do conditional processing when kstatus is
>>> zero at all times except whene there is a message.
>>> But ctrl7 should normally just output the controller value, and the
>>> output should stay at this value until a new midi message arrives.
>>> Additionally, ctrl7 should never output anything in the case that the
>>> status myte of an incoming midi message is zero (and indeed the status
>>> byte should actually never be zero if the sender conforms to the
>>> standard midi spec).
>>>
>>> Some midi controllers that have buttons can be configured to send a
>>> message only when the button is pushed (momentary), and optionally, a
>>> different message when it is pushed and when it is released (toggle).
>>>
>>> Oeyvind
>>>
>>> 2010/4/19 Steven Yi :
>>>> Also, just found this page which has a nice explanation with diagrams
>>>> of status bytes and MIDI data:
>>>>
>>>> http://www.planetoftunes.com/sequence/statdata.html
>>>>
>>>> Which also reminds me that it should be impossible to have a status of
>>>> 0, so it's certainly weird.  Do you have a complete CSD you can post
>>>> here?  I'd like to take a look to see about reproducing here and
>>>> digging in a bit.
>>>>
>>>> Thanks!
>>>> steven
>>>>
>>>> On Mon, Apr 19, 2010 at 12:00 AM, Steven Yi  wrote:
>>>>> Hi Rory,
>>>>>
>>>>> Could you try the project using one of the other midi drivers (winmm,
>>>>> alsa, jack)?  Maybe it's a bug with our pmidi.c driver.
>>>>>
>>>>> steven
>>>>>
>>>>> On Sun, Apr 18, 2010 at 9:29 PM, Rory Walsh  wrote:
>>>>>> Thanks Peiman, that provides a solution to this particular problem but
>>>>>> I'm still curious to know why this status byte of 0 is being sent at
>>>>>> all. Other audio/midi applications don't seem to pick it up. Pd, which
>>>>>> uses the portmidi library too, only reports one message per button
>>>>>> push. I'd assume that most end users would expect one message per
>>>>>> button press. I guess someone might be able to provide a good
>>>>>> explanation as to whether this status byte of 0 can prove useful in
>>>>>> certain situations..
>>>>>>
>>>>>> Rory.
>>>>>>
>>>>>>
>>>>>> 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"
>>>>
>>>>
>>>
>>>
>>> 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"
>>
>>
>
>
> 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"

> Why not this?
>
> k1 ctrl7 1, 7, 0, 127
> if(k1>0) then
> event "i", 1, 0, 10
> endif

I just tried this, and it will not work well as the event opcode will
be trigger not just once but many times. The changed opcode is great
as it only outputs a 1 for a single control period, as far as I can
tell.

Rory.


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"

ahh that's good to know. Thanks for testing it.

Peiman

On 19 Apr 2010, at 11:16, Rory Walsh wrote:

>> Why not this?
>>
>> k1 ctrl7 1, 7, 0, 127
>> if(k1>0) then
>> event "i", 1, 0, 10
>> endif
>
> I just tried this, and it will not work well as the event opcode will
> be trigger not just once but many times. The changed opcode is great
> as it only outputs a 1 for a single control period, as far as I can
> tell.
>
> Rory.
>
>
> 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"