MIDIIN Issue (Windows)

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

MIDIIN Issue (Windows)

abhunkin
I'm trying to get midiin (in a windows context, and in an always-on
instrument) to gate another instrument on and off. I'm having problems and
would appreciate help with the attached basic .csd.

Description of .csd: i128 is a dummy instrument to handle the default MIDI
noteon/noteoff assignments (thanks here to Iain); i129 is the always on
instrument processing the midiin messages and sending various note on and
note off commands to i130, which generates sound.

I've tried (and included) various gating mechanisms: schedkwhen, schedk,
schedule and event. My goal is to find at least one mechanism that works
with *all* Windows Csounds. (For test purposes, I've used 3 Windows Csounds:
CsoundAV, flCsound - representing Csound4, and Csound5Beta.)

Results using these various gating methods in the attached .csd are as
follows:

Event: works correctly in Csound5, not in flCsound or CsoundAV (error in
both).

Schedule: no error in any Csound, but no sound either. (I didn't
particularly expect schedule to work.)

Schedk (AV only): illegal in other Csounds; in CsoundAV, gates on but not
off.

Schedkwhen: in all Csounds, gates on but not off.


Due to the schedk and schedkwhen results, I suspect that the trigger
mechanism for the two is not working correctly - but I can't see it. Maybe
something Istvan said about "event" a few days ago applies here (as in, when
"event" actually takes place). Indeed, coping with a trigger in this
situation is a big trouble and problemmatic; it's simply required for schedk
and schedkwhen (the latter of which I'd normally use).

Regarding the .csd coding options: the lines starting kon and trigger are
only used with schedk and schedkwhen - not with event or schedule. The two
CsOptions lines should work with the various Csounds.

I'm wondering too if there is any significant relationship between the MIDI
data rate which furnishes midiin messages, and Csound's k-rate. I've assumed
that as soon as a k-pass picks up a MIDI message from the buffer that buffer
values immediately revert to zero until another value appears (at least as
far as midiin is concerned). As a result, I also assume that a k-pass
through i129 doesn't do *anything* unless a MIDI note on or off message is
presented (status = 144 or 128).

Any and all advice appreciated. I really would like to get an indirect MIDI
gating mechanism that works for all Windows Csounds. Of course, I realize
that *direct* MIDI gating is easy; I'm looking to more complicated settings,
like a "monosynth" and legato, etc.

TIA -

Art Hunkins

MidiinTest.csd (826 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: MIDIIN Issue (Windows)

Istvan Varga
Art Hunkins wrote:

 > Event: works correctly in Csound5, not in flCsound or CsoundAV (error in
 > both).

Perhaps those other versions of Csound should fix the bug ?

 > Schedule: no error in any Csound, but no sound either. (I didn't
 > particularly expect schedule to work.)

schedule runs at i-time only; you cannot expect it to generate events
at control rate.

 > Schedkwhen: in all Csounds, gates on but not off.

schedkwhen should work (at least it does in Csound 5), you just need to
remove the trigger stuff that is not needed anyway (and the one for note-off
is never activated). Here is a fixed version of your CSD:

<CsoundSynthesizer>
<CsOptions>

;-+K -+P ; for CsoundAV
-M1 -odac ; for other Csounds

</CsOptions>
<CsInstruments>

sr = 44100
ksmps = 32
nchnls = 1

; for Csound 5

;ichn =  1
;lp1:
; massign ichn, 0
; loop_le ichn, 1, 16, lp1
; pgmassign 0, 0

; for older versions of Csound

        instr 128 ; dummy

        endin

        instr 129

; hack to prevent schedkwhen from starting a note at i-time
ktrig init 0
ktrig =  1

kstatus, kchan, kb1, kb2 midiin
        if kstatus == 144 kgoto on
        if kstatus == 128 kgoto off
        kgoto fin
on:
        if kb2 == 0 kgoto off
        schedkwhen ktrig, 0, 0, 130, 0, -1, kb1, kb2
; event "i", 130, 0, -1
; schedule 130, 0, -1
        kgoto fin
off:
        schedkwhen ktrig, 0, 0, -130, 0, 0
; event "i", -130, 0, 0
; schedule -130, 0, 0

fin:
        endin

        instr 130

kamp init  p5 * p5
kcps init  440 * powoftwo((p4 - 69) / 12)

        tigoto skipInit
asig lfo kamp, kcps
skipInit:
        out asig

        endin

</CsInstruments>
<CsScore>

i129 0 3600
e

</CsScore>
</CsoundSynthesizer>
--
Send bugs reports to this list.
To unsubscribe, send email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: MIDIIN Issue (Windows)

abhunkin
It would be really nice if event could work in Csound4 and CsoundAV as well
as Csound5. (In both cases, using "i", Csound crashes with an error window.)
If necessary, I can supply a simple example. (I introduced this thread with
a .csd that illustrated the problem.)

Art Hunkins

----- Original Message -----
From: "Istvan Varga" <[hidden email]>
To: <[hidden email]>
Sent: Tuesday, August 16, 2005 1:36 PM
Subject: Re: [Csnd] MIDIIN Issue (Windows)


> Art Hunkins wrote:
>
>  > Event: works correctly in Csound5, not in flCsound or CsoundAV (error
in
>  > both).
>
> Perhaps those other versions of Csound should fix the bug ?
>

--
Send bugs reports to this list.
To unsubscribe, send email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: MIDIIN Issue (Windows)

abhunkin
In reply to this post by Istvan Varga
Thanks, Istvan.

The solution was indeed as simple as throwing out the trigger stuff and
substituting a 1 for the first arg of schedkwhen. I had no idea you could do
that. (That's another useful detail that would be wonderful to include in
the schedkwhen documentation.)

Can you explain what the loop_le is all about - in your header "for older
versions of Csound"? (AV and flCsound seem to work well for me without these
additions.)

Also, can you tell me why the schedkwhen for note *off* was never being
called in my example? (I'm sure there must be a reason; I just can't see
it.)

Thanks again - as always.

Art Hunkins

----- Original Message -----
From: "Istvan Varga" <[hidden email]>
To: <[hidden email]>
Sent: Tuesday, August 16, 2005 1:36 PM
Subject: Re: [Csnd] MIDIIN Issue (Windows)


> Art Hunkins wrote:
>
>  > Event: works correctly in Csound5, not in flCsound or CsoundAV (error
in both).

>
> Perhaps those other versions of Csound should fix the bug ?
>
>  > Schedule: no error in any Csound, but no sound either. (I didn't
>  > particularly expect schedule to work.)
>
> schedule runs at i-time only; you cannot expect it to generate events
> at control rate.
>
>  > Schedkwhen: in all Csounds, gates on but not off.
>
> schedkwhen should work (at least it does in Csound 5), you just need to
> remove the trigger stuff that is not needed anyway (and the one for
note-off

> is never activated). Here is a fixed version of your CSD:
>
> <CsoundSynthesizer>
> <CsOptions>
>
> ;-+K -+P ; for CsoundAV
> -M1 -odac ; for other Csounds
>
> </CsOptions>
> <CsInstruments>
>
> sr = 44100
> ksmps = 32
> nchnls = 1
>
> ; for Csound 5
>
> ;ichn =  1
> ;lp1:
> ; massign ichn, 0
> ; loop_le ichn, 1, 16, lp1
> ; pgmassign 0, 0
>
> ; for older versions of Csound
>
> instr 128 ; dummy
>
> endin
>
> instr 129
>
> ; hack to prevent schedkwhen from starting a note at i-time
> ktrig init 0
> ktrig =  1
>
> kstatus, kchan, kb1, kb2 midiin
> if kstatus == 144 kgoto on
> if kstatus == 128 kgoto off
> kgoto fin
> on:
> if kb2 == 0 kgoto off
> schedkwhen ktrig, 0, 0, 130, 0, -1, kb1, kb2
> ; event "i", 130, 0, -1
> ; schedule 130, 0, -1
> kgoto fin
> off:
> schedkwhen ktrig, 0, 0, -130, 0, 0
> ; event "i", -130, 0, 0
> ; schedule -130, 0, 0
>
> fin:
> endin
>
> instr 130
>
> kamp init  p5 * p5
> kcps init  440 * powoftwo((p4 - 69) / 12)
>
> tigoto skipInit
> asig lfo kamp, kcps
> skipInit:
> out asig
>
> endin
>
> </CsInstruments>
> <CsScore>
>
> i129 0 3600
> e
>
> </CsScore>
> </CsoundSynthesizer>
> --
> Send bugs reports to this list.
> To unsubscribe, send email to [hidden email]

--
Send bugs reports to this list.
To unsubscribe, send email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: MIDIIN Issue (Windows)

Istvan Varga
In reply to this post by abhunkin
Art Hunkins wrote:

> It would be really nice if event could work in Csound4 and CsoundAV as well
> as Csound5. (In both cases, using "i", Csound crashes with an error window.)
> If necessary, I can supply a simple example. (I introduced this thread with
> a .csd that illustrated the problem.)

Is it possible that you need to use the -L stdin flag ? Some versions of Csound 4
require that for event to work correctly.
--
Send bugs reports to this list.
To unsubscribe, send email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: MIDIIN Issue (Windows)

Istvan Varga
In reply to this post by abhunkin
Art Hunkins wrote:

> The solution was indeed as simple as throwing out the trigger stuff and
> substituting a 1 for the first arg of schedkwhen. I had no idea you could do
> that. (That's another useful detail that would be wonderful to include in
> the schedkwhen documentation.)

Note that if you use a constant 1 instead of a k-rate variable as shown
in the CSD file, you will always get a note at i-time.

> Can you explain what the loop_le is all about - in your header "for older
> versions of Csound"? (AV and flCsound seem to work well for me without these
> additions.)

The following lines disable the activation of any MIDI notes, and make
it not necessary to have a dummy instrument:

ichn    =  1
lp1:
         massign ichn, 0
         loop_le ichn, 1, 16, lp1
         pgmassign 0, 0

The loop_le statement is identical to:

ichn    =  ichn + 1
         if (ichn <= 16) igoto lp1

So, all MIDI channels are muted by being assigned to instr 0, and program
changes are disabled completely with pgmassign.

> Also, can you tell me why the schedkwhen for note *off* was never being
> called in my example? (I'm sure there must be a reason; I just can't see
> it.)

Notice that for both trigger opcodes, the value of kon - which is set just
before the trigger - is always the same (1 for the first, and 0 for the
second one). Thus, knowing that the initial value for the previous input
signal in trigger is zero, the note-on trigger will work only once at the
first time (where it will see a change from 0 to 1), and after that, it
will not turn on any more notes because kon will always be 1 and never
change. The note-off trigger always gets kon=0, and the initial "previous
value" is zero as well; so, there is never a change, and the result is
never having a note-off.

on:
         if kb2 == 0 goto off
kon     =       1
ktrig   trigger kon, .5, 0
;       schedk  ktrig, 0, 130, 0, -1
         schedkwhen      ktrig, 0, 0, 130, 0, -1
;       event   "i", 130, 0, -1
;       schedule        130, 0, -1
         goto fin
off:
kon     =       0
ktrig   trigger kon, .5, 1
;       schedk  ktrig, 0, -130, 0, 0
         schedkwhen      ktrig, 0, 0, -130, 0, 0
;       event   "i", -130, 0, 0
;       schedule        -130, 0, 0

--
Send bugs reports to this list.
To unsubscribe, send email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: MIDIIN Issue (Windows)

abhunkin
Thanks, Istvan. Very helpful.

I'll look further into the issue of using 1 as ktrig in schedkwhen. It is
not giving me any obvious note at init time - but maybe it is causing a
click?

Two observations: massign 1, 0 under both CsoundAV and flCsound(4) both give
"unknown instr" error messages, contrary to Csound5. Csound5 must be
treating instr 0 differently from these others.

I still don't understand about no "note off" in my example. A note has to be
turned on (a key pressed) before one can be turned off. When this happens
kon first becomes 1 *and stays 1* until a note is turned off, whereupon it
becomes 0 (and stays there). This is completely different from what happens
to ktrig, which of course is only momentarily 1 in both cases.

Furthermore, the k-pass only goes through the on and off code during the
pass where a key is pressed or released. At other times those bits of
if...goto code are not run - so I don't see how otherwise the values of kon
(whether 1 or 0) would change; they should stay one or the other until
explicitly changed - at which point a trigger should occur, enabling a
schedkwhen.

Oh well . . .

Art Hunkins

----- Original Message -----
From: "Istvan Varga" <[hidden email]>
To: <[hidden email]>
Sent: Wednesday, August 17, 2005 6:19 AM
Subject: Re: [Csnd] MIDIIN Issue (Windows)


> Art Hunkins wrote:
>
> > The solution was indeed as simple as throwing out the trigger stuff and
> > substituting a 1 for the first arg of schedkwhen. I had no idea you
could do
> > that. (That's another useful detail that would be wonderful to include
in
> > the schedkwhen documentation.)
>
> Note that if you use a constant 1 instead of a k-rate variable as shown
> in the CSD file, you will always get a note at i-time.
>
> > Can you explain what the loop_le is all about - in your header "for
older
> > versions of Csound"? (AV and flCsound seem to work well for me without
these

> > additions.)
>
> The following lines disable the activation of any MIDI notes, and make
> it not necessary to have a dummy instrument:
>
> ichn    =  1
> lp1:
>          massign ichn, 0
>          loop_le ichn, 1, 16, lp1
>          pgmassign 0, 0
>
> The loop_le statement is identical to:
>
> ichn    =  ichn + 1
>          if (ichn <= 16) igoto lp1
>
> So, all MIDI channels are muted by being assigned to instr 0, and program
> changes are disabled completely with pgmassign.
>
> > Also, can you tell me why the schedkwhen for note *off* was never being
> > called in my example? (I'm sure there must be a reason; I just can't see
> > it.)
>
> Notice that for both trigger opcodes, the value of kon - which is set just
> before the trigger - is always the same (1 for the first, and 0 for the
> second one). Thus, knowing that the initial value for the previous input
> signal in trigger is zero, the note-on trigger will work only once at the
> first time (where it will see a change from 0 to 1), and after that, it
> will not turn on any more notes because kon will always be 1 and never
> change. The note-off trigger always gets kon=0, and the initial "previous
> value" is zero as well; so, there is never a change, and the result is
> never having a note-off.
>
> on:
>          if kb2 == 0 goto off
> kon     =       1
> ktrig   trigger kon, .5, 0
> ;       schedk  ktrig, 0, 130, 0, -1
>          schedkwhen      ktrig, 0, 0, 130, 0, -1
> ;       event   "i", 130, 0, -1
> ;       schedule        130, 0, -1
>          goto fin
> off:
> kon     =       0
> ktrig   trigger kon, .5, 1
> ;       schedk  ktrig, 0, -130, 0, 0
>          schedkwhen      ktrig, 0, 0, -130, 0, 0
> ;       event   "i", -130, 0, 0
> ;       schedule        -130, 0, 0
>
> --
> Send bugs reports to this list.
> To unsubscribe, send email to [hidden email]

--
Send bugs reports to this list.
To unsubscribe, send email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: MIDIIN Issue (Windows)

Istvan Varga
Art Hunkins wrote:

> Two observations: massign 1, 0 under both CsoundAV and flCsound(4) both give
> "unknown instr" error messages, contrary to Csound5. Csound5 must be
> treating instr 0 differently from these others.

It is a new feature that zero and negative instrument numbers have the
effect of muting the channel.

> I still don't understand about no "note off" in my example. A note has to be
> turned on (a key pressed) before one can be turned off. When this happens
> kon first becomes 1 *and stays 1* until a note is turned off, whereupon it
> becomes 0 (and stays there). This is completely different from what happens
> to ktrig, which of course is only momentarily 1 in both cases.

While it is true that kon is set to 1 on note-on, and 0 on note-off, however,
the assignments are placed just before the trigger opcodes, and so the triggers
themselves will never see anything else than the value set one line above.
It does not matter that kon may have other values elsewhere.
--
Send bugs reports to this list.
To unsubscribe, send email to [hidden email]