[Csnd] MIDI controller question

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

[Csnd] MIDI controller question

Dave Seidel
I am working on a piece that reads input from a MIDI keyboard (McMillen QuNexus). This is working fine. Now I'd like to also read controller input from my old Evolution UC-16, which is a bank of knobs. So far, I'm not getting any data from the UC-16. I've verified with kmidimon that the UC-16 is working as configured (i.e., channel number and controller numbers).

The keyboard is using channel 1. I use massign to bind this channel to an instrument.

The UC-16 is using channel 2. I'm using ctrl7 to read the data, just on one controller so far, but the kvar that it sets never changes value (I'm using printk2). I've tried using massign two different ways with no success :

  massign 2, 0    ; muted
  massign 2, 20  ; assigned to instr 20

I've also tried not using massign with channel 2 at all, no luck there either.

I'm using -Ma, but even if I use -M5 (the UC-16 is device 5), I don't get any controller data.

I'm sure I'm doing something wrong, or missing something, but I'm stumped. Anyone have any ideas how I can get this working?

Thanks,
Dave

Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
Reply | Threaded
Open this post in threaded view
|

Re: [Csnd] MIDI controller question

Arthur Hunkins
Dave -

Are you saying that with -M5 (and your UC-16 MIDI device #5), no massigns, your UC-16 outputting on channel 2), your .csd doesn't produce an output with ctrl7 on channel 2 (and of course compatible controller numbers)? This surely doesn't make any sense.

That aside, I've three thoughts (all possibly irrelevent):
1) -Ma came somewhat later than midiin and massign. Could something strange be going on in your rather complex setting (maybe showing a limitation of -Ma)?
2) I'm not sure that ctrl7 (which I'm assuming you're using with the UC-16's knobs) responds to massign in the same way that midiin does; indeed I'm not sure that ctrl7 isn't completely independent of massign's assignment to instruments.
3) Could massign, OTOH, be hijacking ctrl7 and forcing it to be assigned as midiin is?

I do know that with -Ma, two MIDI controllers on the same channel or on different channels work together properly with ctrl7. I've never tried two control devices with midiin and/or massign though.

I've a UC-16 and would be happy to try out a simplified example of yours if it would help.

Best -

Art H. 


On Sat, Feb 10, 2018 at 3:27 PM, Dave Seidel <[hidden email]> wrote:
I am working on a piece that reads input from a MIDI keyboard (McMillen QuNexus). This is working fine. Now I'd like to also read controller input from my old Evolution UC-16, which is a bank of knobs. So far, I'm not getting any data from the UC-16. I've verified with kmidimon that the UC-16 is working as configured (i.e., channel number and controller numbers).

The keyboard is using channel 1. I use massign to bind this channel to an instrument.

The UC-16 is using channel 2. I'm using ctrl7 to read the data, just on one controller so far, but the kvar that it sets never changes value (I'm using printk2). I've tried using massign two different ways with no success :

  massign 2, 0    ; muted
  massign 2, 20  ; assigned to instr 20

I've also tried not using massign with channel 2 at all, no luck there either.

I'm using -Ma, but even if I use -M5 (the UC-16 is device 5), I don't get any controller data.

I'm sure I'm doing something wrong, or missing something, but I'm stumped. Anyone have any ideas how I can get this working?

Thanks,
Dave

Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
Reply | Threaded
Open this post in threaded view
|

Re: [Csnd] MIDI controller question

Dave Seidel
Hi Art,

Thanks for jumping in! Figured it out, and the reason was surprising. It seems that

    gk1 = ctrl7(2, 103, 0, 1)

does not work the same as

    gk1 ctrl7 2, 103, 0, 1

Specifically, if I use the new functional syntax as in the former example (which I prefer), the statement seems to only execute once (at init time). But in the latter form (old style), it works exactly as expected. There's no conflict between massign and ctrl7.

I will probably write this up as a bug tomorrow.

- Dave

On Sat, Feb 10, 2018 at 7:40 PM, Arthur Hunkins <[hidden email]> wrote:
Dave -

Are you saying that with -M5 (and your UC-16 MIDI device #5), no massigns, your UC-16 outputting on channel 2), your .csd doesn't produce an output with ctrl7 on channel 2 (and of course compatible controller numbers)? This surely doesn't make any sense.

That aside, I've three thoughts (all possibly irrelevent):
1) -Ma came somewhat later than midiin and massign. Could something strange be going on in your rather complex setting (maybe showing a limitation of -Ma)?
2) I'm not sure that ctrl7 (which I'm assuming you're using with the UC-16's knobs) responds to massign in the same way that midiin does; indeed I'm not sure that ctrl7 isn't completely independent of massign's assignment to instruments.
3) Could massign, OTOH, be hijacking ctrl7 and forcing it to be assigned as midiin is?

I do know that with -Ma, two MIDI controllers on the same channel or on different channels work together properly with ctrl7. I've never tried two control devices with midiin and/or massign though.

I've a UC-16 and would be happy to try out a simplified example of yours if it would help.

Best -

Art H. 


On Sat, Feb 10, 2018 at 3:27 PM, Dave Seidel <[hidden email]> wrote:
I am working on a piece that reads input from a MIDI keyboard (McMillen QuNexus). This is working fine. Now I'd like to also read controller input from my old Evolution UC-16, which is a bank of knobs. So far, I'm not getting any data from the UC-16. I've verified with kmidimon that the UC-16 is working as configured (i.e., channel number and controller numbers).

The keyboard is using channel 1. I use massign to bind this channel to an instrument.

The UC-16 is using channel 2. I'm using ctrl7 to read the data, just on one controller so far, but the kvar that it sets never changes value (I'm using printk2). I've tried using massign two different ways with no success :

  massign 2, 0    ; muted
  massign 2, 20  ; assigned to instr 20

I've also tried not using massign with channel 2 at all, no luck there either.

I'm using -Ma, but even if I use -M5 (the UC-16 is device 5), I don't get any controller data.

I'm sure I'm doing something wrong, or missing something, but I'm stumped. Anyone have any ideas how I can get this working?

Thanks,
Dave

Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here



--
Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
Reply | Threaded
Open this post in threaded view
|

Re: [Csnd] MIDI controller question

Tarmo Johannes-3
Hi,

With functional syntax you may need to specify type, to be certain which overload is used. Try
ctr7:k(...etc

Not sure if that was the reason and strange ot worked with first device in that case.

Tarmo

11.02.2018 4:46 kirjutas kuupäeval "Dave Seidel" <[hidden email]>:
Hi Art,

Thanks for jumping in! Figured it out, and the reason was surprising. It seems that

    gk1 = ctrl7(2, 103, 0, 1)

does not work the same as

    gk1 ctrl7 2, 103, 0, 1

Specifically, if I use the new functional syntax as in the former example (which I prefer), the statement seems to only execute once (at init time). But in the latter form (old style), it works exactly as expected. There's no conflict between massign and ctrl7.

I will probably write this up as a bug tomorrow.

- Dave

On Sat, Feb 10, 2018 at 7:40 PM, Arthur Hunkins <[hidden email]> wrote:
Dave -

Are you saying that with -M5 (and your UC-16 MIDI device #5), no massigns, your UC-16 outputting on channel 2), your .csd doesn't produce an output with ctrl7 on channel 2 (and of course compatible controller numbers)? This surely doesn't make any sense.

That aside, I've three thoughts (all possibly irrelevent):
1) -Ma came somewhat later than midiin and massign. Could something strange be going on in your rather complex setting (maybe showing a limitation of -Ma)?
2) I'm not sure that ctrl7 (which I'm assuming you're using with the UC-16's knobs) responds to massign in the same way that midiin does; indeed I'm not sure that ctrl7 isn't completely independent of massign's assignment to instruments.
3) Could massign, OTOH, be hijacking ctrl7 and forcing it to be assigned as midiin is?

I do know that with -Ma, two MIDI controllers on the same channel or on different channels work together properly with ctrl7. I've never tried two control devices with midiin and/or massign though.

I've a UC-16 and would be happy to try out a simplified example of yours if it would help.

Best -

Art H. 


On Sat, Feb 10, 2018 at 3:27 PM, Dave Seidel <[hidden email]> wrote:
I am working on a piece that reads input from a MIDI keyboard (McMillen QuNexus). This is working fine. Now I'd like to also read controller input from my old Evolution UC-16, which is a bank of knobs. So far, I'm not getting any data from the UC-16. I've verified with kmidimon that the UC-16 is working as configured (i.e., channel number and controller numbers).

The keyboard is using channel 1. I use massign to bind this channel to an instrument.

The UC-16 is using channel 2. I'm using ctrl7 to read the data, just on one controller so far, but the kvar that it sets never changes value (I'm using printk2). I've tried using massign two different ways with no success :

  massign 2, 0    ; muted
  massign 2, 20  ; assigned to instr 20

I've also tried not using massign with channel 2 at all, no luck there either.

I'm using -Ma, but even if I use -M5 (the UC-16 is device 5), I don't get any controller data.

I'm sure I'm doing something wrong, or missing something, but I'm stumped. Anyone have any ideas how I can get this working?

Thanks,
Dave

Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here



--
Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
Reply | Threaded
Open this post in threaded view
|

Re: [Csnd] MIDI controller question

Victor Lazzarini-2
In reply to this post by Dave Seidel
it’s not a bug. You need to give it a type hint

kvar = ctrl7:k(...)

because otherwise the i-time opcode will be called (there is no out type inference in this form).

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

On 11 Feb 2018, at 02:47, Dave Seidel <[hidden email]> wrote:

Hi Art,

Thanks for jumping in! Figured it out, and the reason was surprising. It seems that

    gk1 = ctrl7(2, 103, 0, 1)

does not work the same as

    gk1 ctrl7 2, 103, 0, 1

Specifically, if I use the new functional syntax as in the former example (which I prefer), the statement seems to only execute once (at init time). But in the latter form (old style), it works exactly as expected. There's no conflict between massign and ctrl7.

I will probably write this up as a bug tomorrow.

- Dave

On Sat, Feb 10, 2018 at 7:40 PM, Arthur Hunkins <[hidden email]> wrote:
Dave -

Are you saying that with -M5 (and your UC-16 MIDI device #5), no massigns, your UC-16 outputting on channel 2), your .csd doesn't produce an output with ctrl7 on channel 2 (and of course compatible controller numbers)? This surely doesn't make any sense.

That aside, I've three thoughts (all possibly irrelevent):
1) -Ma came somewhat later than midiin and massign. Could something strange be going on in your rather complex setting (maybe showing a limitation of -Ma)?
2) I'm not sure that ctrl7 (which I'm assuming you're using with the UC-16's knobs) responds to massign in the same way that midiin does; indeed I'm not sure that ctrl7 isn't completely independent of massign's assignment to instruments.
3) Could massign, OTOH, be hijacking ctrl7 and forcing it to be assigned as midiin is?

I do know that with -Ma, two MIDI controllers on the same channel or on different channels work together properly with ctrl7. I've never tried two control devices with midiin and/or massign though.

I've a UC-16 and would be happy to try out a simplified example of yours if it would help.

Best -

Art H. 


On Sat, Feb 10, 2018 at 3:27 PM, Dave Seidel <[hidden email]> wrote:
I am working on a piece that reads input from a MIDI keyboard (McMillen QuNexus). This is working fine. Now I'd like to also read controller input from my old Evolution UC-16, which is a bank of knobs. So far, I'm not getting any data from the UC-16. I've verified with kmidimon that the UC-16 is working as configured (i.e., channel number and controller numbers).

The keyboard is using channel 1. I use massign to bind this channel to an instrument.

The UC-16 is using channel 2. I'm using ctrl7 to read the data, just on one controller so far, but the kvar that it sets never changes value (I'm using printk2). I've tried using massign two different ways with no success :

  massign 2, 0    ; muted
  massign 2, 20  ; assigned to instr 20

I've also tried not using massign with channel 2 at all, no luck there either.

I'm using -Ma, but even if I use -M5 (the UC-16 is device 5), I don't get any controller data.

I'm sure I'm doing something wrong, or missing something, but I'm stumped. Anyone have any ideas how I can get this working?

Thanks,
Dave

Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here



--
Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
Reply | Threaded
Open this post in threaded view
|

Re: [Csnd] MIDI controller question

Dave Seidel
Point taken, Victor. This is the part of the new syntax that I keep forgetting about, because it's just not intuitive. After having spent several hours trying to figure this out, I wish there was, perhaps, some level of warnings that could be used to emit warnings on type inferences. Are there any plans to eventually extend type inference to take the out type into account?

On Sun, Feb 11, 2018 at 5:08 AM, Victor Lazzarini <[hidden email]> wrote:
it’s not a bug. You need to give it a type hint

kvar = ctrl7:k(...)

because otherwise the i-time opcode will be called (there is no out type inference in this form).

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

On 11 Feb 2018, at 02:47, Dave Seidel <[hidden email]> wrote:

Hi Art,

Thanks for jumping in! Figured it out, and the reason was surprising. It seems that

    gk1 = ctrl7(2, 103, 0, 1)

does not work the same as

    gk1 ctrl7 2, 103, 0, 1

Specifically, if I use the new functional syntax as in the former example (which I prefer), the statement seems to only execute once (at init time). But in the latter form (old style), it works exactly as expected. There's no conflict between massign and ctrl7.

I will probably write this up as a bug tomorrow.

- Dave

On Sat, Feb 10, 2018 at 7:40 PM, Arthur Hunkins <[hidden email]> wrote:
Dave -

Are you saying that with -M5 (and your UC-16 MIDI device #5), no massigns, your UC-16 outputting on channel 2), your .csd doesn't produce an output with ctrl7 on channel 2 (and of course compatible controller numbers)? This surely doesn't make any sense.

That aside, I've three thoughts (all possibly irrelevent):
1) -Ma came somewhat later than midiin and massign. Could something strange be going on in your rather complex setting (maybe showing a limitation of -Ma)?
2) I'm not sure that ctrl7 (which I'm assuming you're using with the UC-16's knobs) responds to massign in the same way that midiin does; indeed I'm not sure that ctrl7 isn't completely independent of massign's assignment to instruments.
3) Could massign, OTOH, be hijacking ctrl7 and forcing it to be assigned as midiin is?

I do know that with -Ma, two MIDI controllers on the same channel or on different channels work together properly with ctrl7. I've never tried two control devices with midiin and/or massign though.

I've a UC-16 and would be happy to try out a simplified example of yours if it would help.

Best -

Art H. 


On Sat, Feb 10, 2018 at 3:27 PM, Dave Seidel <[hidden email]> wrote:
I am working on a piece that reads input from a MIDI keyboard (McMillen QuNexus). This is working fine. Now I'd like to also read controller input from my old Evolution UC-16, which is a bank of knobs. So far, I'm not getting any data from the UC-16. I've verified with kmidimon that the UC-16 is working as configured (i.e., channel number and controller numbers).

The keyboard is using channel 1. I use massign to bind this channel to an instrument.

The UC-16 is using channel 2. I'm using ctrl7 to read the data, just on one controller so far, but the kvar that it sets never changes value (I'm using printk2). I've tried using massign two different ways with no success :

  massign 2, 0    ; muted
  massign 2, 20  ; assigned to instr 20

I've also tried not using massign with channel 2 at all, no luck there either.

I'm using -Ma, but even if I use -M5 (the UC-16 is device 5), I don't get any controller data.

I'm sure I'm doing something wrong, or missing something, but I'm stumped. Anyone have any ideas how I can get this working?

Thanks,
Dave

Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here



--
Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here



--
Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
Reply | Threaded
Open this post in threaded view
|

Re: [Csnd] MIDI controller question

Victor Lazzarini-2
We have some plans for better type inference on Csound 7. The parser needs to
do some different for that to happen.

The thing is that at the moment, there is
nothing wrong with the line, from the
parser perspective, because it’s
legal to assign k = i, therefore it is not
possible to tell what the user wants 
without a type hint.

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

On 11 Feb 2018, at 13:14, Dave Seidel <[hidden email]> wrote:

Point taken, Victor. This is the part of the new syntax that I keep forgetting about, because it's just not intuitive. After having spent several hours trying to figure this out, I wish there was, perhaps, some level of warnings that could be used to emit warnings on type inferences. Are there any plans to eventually extend type inference to take the out type into account?

On Sun, Feb 11, 2018 at 5:08 AM, Victor Lazzarini <[hidden email]> wrote:
it’s not a bug. You need to give it a type hint

kvar = ctrl7:k(...)

because otherwise the i-time opcode will be called (there is no out type inference in this form).

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

On 11 Feb 2018, at 02:47, Dave Seidel <[hidden email]> wrote:

Hi Art,

Thanks for jumping in! Figured it out, and the reason was surprising. It seems that

    gk1 = ctrl7(2, 103, 0, 1)

does not work the same as

    gk1 ctrl7 2, 103, 0, 1

Specifically, if I use the new functional syntax as in the former example (which I prefer), the statement seems to only execute once (at init time). But in the latter form (old style), it works exactly as expected. There's no conflict between massign and ctrl7.

I will probably write this up as a bug tomorrow.

- Dave

On Sat, Feb 10, 2018 at 7:40 PM, Arthur Hunkins <[hidden email]> wrote:
Dave -

Are you saying that with -M5 (and your UC-16 MIDI device #5), no massigns, your UC-16 outputting on channel 2), your .csd doesn't produce an output with ctrl7 on channel 2 (and of course compatible controller numbers)? This surely doesn't make any sense.

That aside, I've three thoughts (all possibly irrelevent):
1) -Ma came somewhat later than midiin and massign. Could something strange be going on in your rather complex setting (maybe showing a limitation of -Ma)?
2) I'm not sure that ctrl7 (which I'm assuming you're using with the UC-16's knobs) responds to massign in the same way that midiin does; indeed I'm not sure that ctrl7 isn't completely independent of massign's assignment to instruments.
3) Could massign, OTOH, be hijacking ctrl7 and forcing it to be assigned as midiin is?

I do know that with -Ma, two MIDI controllers on the same channel or on different channels work together properly with ctrl7. I've never tried two control devices with midiin and/or massign though.

I've a UC-16 and would be happy to try out a simplified example of yours if it would help.

Best -

Art H. 


On Sat, Feb 10, 2018 at 3:27 PM, Dave Seidel <[hidden email]> wrote:
I am working on a piece that reads input from a MIDI keyboard (McMillen QuNexus). This is working fine. Now I'd like to also read controller input from my old Evolution UC-16, which is a bank of knobs. So far, I'm not getting any data from the UC-16. I've verified with kmidimon that the UC-16 is working as configured (i.e., channel number and controller numbers).

The keyboard is using channel 1. I use massign to bind this channel to an instrument.

The UC-16 is using channel 2. I'm using ctrl7 to read the data, just on one controller so far, but the kvar that it sets never changes value (I'm using printk2). I've tried using massign two different ways with no success :

  massign 2, 0    ; muted
  massign 2, 20  ; assigned to instr 20

I've also tried not using massign with channel 2 at all, no luck there either.

I'm using -Ma, but even if I use -M5 (the UC-16 is device 5), I don't get any controller data.

I'm sure I'm doing something wrong, or missing something, but I'm stumped. Anyone have any ideas how I can get this working?

Thanks,
Dave

Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here



--
Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here



--
Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
Reply | Threaded
Open this post in threaded view
|

Re: [Csnd] MIDI controller question

Steven Yi
In reply to this post by Dave Seidel
The out types are taken into account. But we have in the language the ability to define opcodes with the same in args (arity and types) and different out args. And in this case both i- and k-types would be semantically viable for the code in context. It's ambiguous because of this kind of overloading. I thought thiugh we had a rule of highest rate first (which is determined by first match in OENTRY table) but maybe it's the other way (as seen here with ctrl7, but this could be a bug here too...)

Anyways, a warning could certainly be added that prints when multiple matching opcodes are found and the default is used. Seems very useful to have.

On Sun, Feb 11, 2018, 08:13 Dave Seidel <[hidden email]> wrote:
Point taken, Victor. This is the part of the new syntax that I keep forgetting about, because it's just not intuitive. After having spent several hours trying to figure this out, I wish there was, perhaps, some level of warnings that could be used to emit warnings on type inferences. Are there any plans to eventually extend type inference to take the out type into account?

On Sun, Feb 11, 2018 at 5:08 AM, Victor Lazzarini <[hidden email]> wrote:
it’s not a bug. You need to give it a type hint

kvar = ctrl7:k(...)

because otherwise the i-time opcode will be called (there is no out type inference in this form).

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

On 11 Feb 2018, at 02:47, Dave Seidel <[hidden email]> wrote:

Hi Art,

Thanks for jumping in! Figured it out, and the reason was surprising. It seems that

    gk1 = ctrl7(2, 103, 0, 1)

does not work the same as

    gk1 ctrl7 2, 103, 0, 1

Specifically, if I use the new functional syntax as in the former example (which I prefer), the statement seems to only execute once (at init time). But in the latter form (old style), it works exactly as expected. There's no conflict between massign and ctrl7.

I will probably write this up as a bug tomorrow.

- Dave

On Sat, Feb 10, 2018 at 7:40 PM, Arthur Hunkins <[hidden email]> wrote:
Dave -

Are you saying that with -M5 (and your UC-16 MIDI device #5), no massigns, your UC-16 outputting on channel 2), your .csd doesn't produce an output with ctrl7 on channel 2 (and of course compatible controller numbers)? This surely doesn't make any sense.

That aside, I've three thoughts (all possibly irrelevent):
1) -Ma came somewhat later than midiin and massign. Could something strange be going on in your rather complex setting (maybe showing a limitation of -Ma)?
2) I'm not sure that ctrl7 (which I'm assuming you're using with the UC-16's knobs) responds to massign in the same way that midiin does; indeed I'm not sure that ctrl7 isn't completely independent of massign's assignment to instruments.
3) Could massign, OTOH, be hijacking ctrl7 and forcing it to be assigned as midiin is?

I do know that with -Ma, two MIDI controllers on the same channel or on different channels work together properly with ctrl7. I've never tried two control devices with midiin and/or massign though.

I've a UC-16 and would be happy to try out a simplified example of yours if it would help.

Best -

Art H. 


On Sat, Feb 10, 2018 at 3:27 PM, Dave Seidel <[hidden email]> wrote:
I am working on a piece that reads input from a MIDI keyboard (McMillen QuNexus). This is working fine. Now I'd like to also read controller input from my old Evolution UC-16, which is a bank of knobs. So far, I'm not getting any data from the UC-16. I've verified with kmidimon that the UC-16 is working as configured (i.e., channel number and controller numbers).

The keyboard is using channel 1. I use massign to bind this channel to an instrument.

The UC-16 is using channel 2. I'm using ctrl7 to read the data, just on one controller so far, but the kvar that it sets never changes value (I'm using printk2). I've tried using massign two different ways with no success :

  massign 2, 0    ; muted
  massign 2, 20  ; assigned to instr 20

I've also tried not using massign with channel 2 at all, no luck there either.

I'm using -Ma, but even if I use -M5 (the UC-16 is device 5), I don't get any controller data.

I'm sure I'm doing something wrong, or missing something, but I'm stumped. Anyone have any ideas how I can get this working?

Thanks,
Dave

Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here



--
Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here



--
Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
Reply | Threaded
Open this post in threaded view
|

Re: [Csnd] MIDI controller question

Victor Lazzarini-2
I am not sure we have gone systematically looking at the oentry tables to place the highest rate first, but it’s worth deciding the
rule and implementing.

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

On 11 Feb 2018, at 13:53, Steven Yi <[hidden email]> wrote:

The out types are taken into account. But we have in the language the ability to define opcodes with the same in args (arity and types) and different out args. And in this case both i- and k-types would be semantically viable for the code in context. It's ambiguous because of this kind of overloading. I thought thiugh we had a rule of highest rate first (which is determined by first match in OENTRY table) but maybe it's the other way (as seen here with ctrl7, but this could be a bug here too...)

Anyways, a warning could certainly be added that prints when multiple matching opcodes are found and the default is used. Seems very useful to have.

On Sun, Feb 11, 2018, 08:13 Dave Seidel <[hidden email]> wrote:
Point taken, Victor. This is the part of the new syntax that I keep forgetting about, because it's just not intuitive. After having spent several hours trying to figure this out, I wish there was, perhaps, some level of warnings that could be used to emit warnings on type inferences. Are there any plans to eventually extend type inference to take the out type into account?

On Sun, Feb 11, 2018 at 5:08 AM, Victor Lazzarini <[hidden email]> wrote:
it’s not a bug. You need to give it a type hint

kvar = ctrl7:k(...)

because otherwise the i-time opcode will be called (there is no out type inference in this form).

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

On 11 Feb 2018, at 02:47, Dave Seidel <[hidden email]> wrote:

Hi Art,

Thanks for jumping in! Figured it out, and the reason was surprising. It seems that

    gk1 = ctrl7(2, 103, 0, 1)

does not work the same as

    gk1 ctrl7 2, 103, 0, 1

Specifically, if I use the new functional syntax as in the former example (which I prefer), the statement seems to only execute once (at init time). But in the latter form (old style), it works exactly as expected. There's no conflict between massign and ctrl7.

I will probably write this up as a bug tomorrow.

- Dave

On Sat, Feb 10, 2018 at 7:40 PM, Arthur Hunkins <[hidden email]> wrote:
Dave -

Are you saying that with -M5 (and your UC-16 MIDI device #5), no massigns, your UC-16 outputting on channel 2), your .csd doesn't produce an output with ctrl7 on channel 2 (and of course compatible controller numbers)? This surely doesn't make any sense.

That aside, I've three thoughts (all possibly irrelevent):
1) -Ma came somewhat later than midiin and massign. Could something strange be going on in your rather complex setting (maybe showing a limitation of -Ma)?
2) I'm not sure that ctrl7 (which I'm assuming you're using with the UC-16's knobs) responds to massign in the same way that midiin does; indeed I'm not sure that ctrl7 isn't completely independent of massign's assignment to instruments.
3) Could massign, OTOH, be hijacking ctrl7 and forcing it to be assigned as midiin is?

I do know that with -Ma, two MIDI controllers on the same channel or on different channels work together properly with ctrl7. I've never tried two control devices with midiin and/or massign though.

I've a UC-16 and would be happy to try out a simplified example of yours if it would help.

Best -

Art H. 


On Sat, Feb 10, 2018 at 3:27 PM, Dave Seidel <[hidden email]> wrote:
I am working on a piece that reads input from a MIDI keyboard (McMillen QuNexus). This is working fine. Now I'd like to also read controller input from my old Evolution UC-16, which is a bank of knobs. So far, I'm not getting any data from the UC-16. I've verified with kmidimon that the UC-16 is working as configured (i.e., channel number and controller numbers).

The keyboard is using channel 1. I use massign to bind this channel to an instrument.

The UC-16 is using channel 2. I'm using ctrl7 to read the data, just on one controller so far, but the kvar that it sets never changes value (I'm using printk2). I've tried using massign two different ways with no success :

  massign 2, 0    ; muted
  massign 2, 20  ; assigned to instr 20

I've also tried not using massign with channel 2 at all, no luck there either.

I'm using -Ma, but even if I use -M5 (the UC-16 is device 5), I don't get any controller data.

I'm sure I'm doing something wrong, or missing something, but I'm stumped. Anyone have any ideas how I can get this working?

Thanks,
Dave

Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here



--
Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here



--
Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
Reply | Threaded
Open this post in threaded view
|

Re: [Csnd] MIDI controller question

jpff
I suspect many opcodes additional the table in the 'obvious' order i,k,a

⁣Sent from TypeApp ​

On Feb 11, 2018, 14:01, at 14:01, Victor Lazzarini <[hidden email]> wrote:

>I am not sure we have gone systematically looking at the oentry tables
>to place the highest rate first, but it’s worth deciding the
>rule and implementing.
>
>Victor Lazzarini
>Dean of Arts, Celtic Studies, and Philosophy
>Maynooth University
>Ireland
>
>On 11 Feb 2018, at 13:53, Steven Yi
><[hidden email]<mailto:[hidden email]>> wrote:
>
>The out types are taken into account. But we have in the language the
>ability to define opcodes with the same in args (arity and types) and
>different out args. And in this case both i- and k-types would be
>semantically viable for the code in context. It's ambiguous because of
>this kind of overloading. I thought thiugh we had a rule of highest
>rate first (which is determined by first match in OENTRY table) but
>maybe it's the other way (as seen here with ctrl7, but this could be a
>bug here too...)
>
>Anyways, a warning could certainly be added that prints when multiple
>matching opcodes are found and the default is used. Seems very useful
>to have.
>
>On Sun, Feb 11, 2018, 08:13 Dave Seidel
><[hidden email]<mailto:[hidden email]>> wrote:
>Point taken, Victor. This is the part of the new syntax that I keep
>forgetting about, because it's just not intuitive. After having spent
>several hours trying to figure this out, I wish there was, perhaps,
>some level of warnings that could be used to emit warnings on type
>inferences. Are there any plans to eventually extend type inference to
>take the out type into account?
>
>On Sun, Feb 11, 2018 at 5:08 AM, Victor Lazzarini
><[hidden email]<mailto:[hidden email]>> wrote:
>it’s not a bug. You need to give it a type hint
>
>kvar = ctrl7:k(...)
>
>because otherwise the i-time opcode will be called (there is no out
>type inference in this form).
>
>Victor Lazzarini
>Dean of Arts, Celtic Studies, and Philosophy
>Maynooth University
>Ireland
>
>On 11 Feb 2018, at 02:47, Dave Seidel
><[hidden email]<mailto:[hidden email]>> wrote:
>
>Hi Art,
>
>Thanks for jumping in! Figured it out, and the reason was surprising.
>It seems that
>
>    gk1 = ctrl7(2, 103, 0, 1)
>
>does not work the same as
>
>    gk1 ctrl7 2, 103, 0, 1
>
>Specifically, if I use the new functional syntax as in the former
>example (which I prefer), the statement seems to only execute once (at
>init time). But in the latter form (old style), it works exactly as
>expected. There's no conflict between massign and ctrl7.
>
>I will probably write this up as a bug tomorrow.
>
>- Dave
>
>On Sat, Feb 10, 2018 at 7:40 PM, Arthur Hunkins
><[hidden email]<mailto:[hidden email]>>
>wrote:
>Dave -
>
>Are you saying that with -M5 (and your UC-16 MIDI device #5), no
>massigns, your UC-16 outputting on channel 2), your .csd doesn't
>produce an output with ctrl7 on channel 2 (and of course compatible
>controller numbers)? This surely doesn't make any sense.
>
>That aside, I've three thoughts (all possibly irrelevent):
>1) -Ma came somewhat later than midiin and massign. Could something
>strange be going on in your rather complex setting (maybe showing a
>limitation of -Ma)?
>2) I'm not sure that ctrl7 (which I'm assuming you're using with the
>UC-16's knobs) responds to massign in the same way that midiin does;
>indeed I'm not sure that ctrl7 isn't completely independent of
>massign's assignment to instruments.
>3) Could massign, OTOH, be hijacking ctrl7 and forcing it to be
>assigned as midiin is?
>
>I do know that with -Ma, two MIDI controllers on the same channel or on
>different channels work together properly with ctrl7. I've never tried
>two control devices with midiin and/or massign though.
>
>I've a UC-16 and would be happy to try out a simplified example of
>yours if it would help.
>
>Best -
>
>Art H.
>
>Art Hunkins
>http://www.arthunkins.com
>
>On Sat, Feb 10, 2018 at 3:27 PM, Dave Seidel
><[hidden email]<mailto:[hidden email]>> wrote:
>I am working on a piece that reads input from a MIDI keyboard (McMillen
>QuNexus). This is working fine. Now I'd like to also read controller
>input from my old Evolution UC-16, which is a bank of knobs. So far,
>I'm not getting any data from the UC-16. I've verified with kmidimon
>that the UC-16 is working as configured (i.e., channel number and
>controller numbers).
>
>The keyboard is using channel 1. I use massign to bind this channel to
>an instrument.
>
>The UC-16 is using channel 2. I'm using ctrl7 to read the data, just on
>one controller so far, but the kvar that it sets never changes value
>(I'm using printk2). I've tried using massign two different ways with
>no success :
>
>  massign 2, 0    ; muted
>  massign 2, 20  ; assigned to instr 20
>
>I've also tried not using massign with channel 2 at all, no luck there
>either.
>
>I'm using -Ma, but even if I use -M5 (the UC-16 is device 5), I don't
>get any controller data.
>
>I'm sure I'm doing something wrong, or missing something, but I'm
>stumped. Anyone have any ideas how I can get this working?
>
>Thanks,
>Dave
>
>Csound mailing list
>[hidden email]<mailto:[hidden email]>
>https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>https://github.com/csound/csound/issues Discussions of bugs and
>features can be posted here
>
>Csound mailing list
>[hidden email]<mailto:[hidden email]>
>https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>https://github.com/csound/csound/issues Discussions of bugs and
>features can be posted here
>
>
>
>--
>http://mysterybear.net
>https://soundcloud.com/mysterybear
>https://mysterybear.bandcamp.com
>
>http://recordings.irritablehedgehog.com/album/dave-seidel-60-hz
>Csound mailing list
>[hidden email]<mailto:[hidden email]>
>https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>https://github.com/csound/csound/issues Discussions of bugs and
>features can be posted here
>Csound mailing list
>[hidden email]<mailto:[hidden email]>
>https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>https://github.com/csound/csound/issues Discussions of bugs and
>features can be posted here
>
>
>
>--
>http://mysterybear.net
>https://soundcloud.com/mysterybear
>https://mysterybear.bandcamp.com
>
>http://recordings.irritablehedgehog.com/album/dave-seidel-60-hz
>Csound mailing list
>[hidden email]<mailto:[hidden email]>
>https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>https://github.com/csound/csound/issues Discussions of bugs and
>features can be posted here
>Csound mailing list
>[hidden email]<mailto:[hidden email]>
>https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>https://github.com/csound/csound/issues Discussions of bugs and
>features can be posted here
>
>Csound mailing list
>[hidden email]
>https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>Send bugs reports to
>        https://github.com/csound/csound/issues
>Discussions of bugs and features can be posted here

Csound mailing list
[hidden email]
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here
Reply | Threaded
Open this post in threaded view
|

Re: [Csnd] MIDI controller question

Dave Seidel
In reply to this post by Victor Lazzarini-2
I like the idea of deferring to the highest rate in the expression, and glad you think the warning is worth considering. It might have saved me a couple of hours. :-)

On Sun, Feb 11, 2018 at 9:00 AM, Victor Lazzarini <[hidden email]> wrote:
I am not sure we have gone systematically looking at the oentry tables to place the highest rate first, but it’s worth deciding the
rule and implementing.

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

On 11 Feb 2018, at 13:53, Steven Yi <[hidden email]> wrote:

The out types are taken into account. But we have in the language the ability to define opcodes with the same in args (arity and types) and different out args. And in this case both i- and k-types would be semantically viable for the code in context. It's ambiguous because of this kind of overloading. I thought thiugh we had a rule of highest rate first (which is determined by first match in OENTRY table) but maybe it's the other way (as seen here with ctrl7, but this could be a bug here too...)

Anyways, a warning could certainly be added that prints when multiple matching opcodes are found and the default is used. Seems very useful to have.

On Sun, Feb 11, 2018, 08:13 Dave Seidel <[hidden email]> wrote:
Point taken, Victor. This is the part of the new syntax that I keep forgetting about, because it's just not intuitive. After having spent several hours trying to figure this out, I wish there was, perhaps, some level of warnings that could be used to emit warnings on type inferences. Are there any plans to eventually extend type inference to take the out type into account?

On Sun, Feb 11, 2018 at 5:08 AM, Victor Lazzarini <[hidden email]> wrote:
it’s not a bug. You need to give it a type hint

kvar = ctrl7:k(...)

because otherwise the i-time opcode will be called (there is no out type inference in this form).

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

On 11 Feb 2018, at 02:47, Dave Seidel <[hidden email]> wrote:

Hi Art,

Thanks for jumping in! Figured it out, and the reason was surprising. It seems that

    gk1 = ctrl7(2, 103, 0, 1)

does not work the same as

    gk1 ctrl7 2, 103, 0, 1

Specifically, if I use the new functional syntax as in the former example (which I prefer), the statement seems to only execute once (at init time). But in the latter form (old style), it works exactly as expected. There's no conflict between massign and ctrl7.

I will probably write this up as a bug tomorrow.

- Dave

On Sat, Feb 10, 2018 at 7:40 PM, Arthur Hunkins <[hidden email]> wrote:
Dave -

Are you saying that with -M5 (and your UC-16 MIDI device #5), no massigns, your UC-16 outputting on channel 2), your .csd doesn't produce an output with ctrl7 on channel 2 (and of course compatible controller numbers)? This surely doesn't make any sense.

That aside, I've three thoughts (all possibly irrelevent):
1) -Ma came somewhat later than midiin and massign. Could something strange be going on in your rather complex setting (maybe showing a limitation of -Ma)?
2) I'm not sure that ctrl7 (which I'm assuming you're using with the UC-16's knobs) responds to massign in the same way that midiin does; indeed I'm not sure that ctrl7 isn't completely independent of massign's assignment to instruments.
3) Could massign, OTOH, be hijacking ctrl7 and forcing it to be assigned as midiin is?

I do know that with -Ma, two MIDI controllers on the same channel or on different channels work together properly with ctrl7. I've never tried two control devices with midiin and/or massign though.

I've a UC-16 and would be happy to try out a simplified example of yours if it would help.

Best -

Art H. 


On Sat, Feb 10, 2018 at 3:27 PM, Dave Seidel <[hidden email]> wrote:
I am working on a piece that reads input from a MIDI keyboard (McMillen QuNexus). This is working fine. Now I'd like to also read controller input from my old Evolution UC-16, which is a bank of knobs. So far, I'm not getting any data from the UC-16. I've verified with kmidimon that the UC-16 is working as configured (i.e., channel number and controller numbers).

The keyboard is using channel 1. I use massign to bind this channel to an instrument.

The UC-16 is using channel 2. I'm using ctrl7 to read the data, just on one controller so far, but the kvar that it sets never changes value (I'm using printk2). I've tried using massign two different ways with no success :

  massign 2, 0    ; muted
  massign 2, 20  ; assigned to instr 20

I've also tried not using massign with channel 2 at all, no luck there either.

I'm using -Ma, but even if I use -M5 (the UC-16 is device 5), I don't get any controller data.

I'm sure I'm doing something wrong, or missing something, but I'm stumped. Anyone have any ideas how I can get this working?

Thanks,
Dave

Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here



--
Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here



--
Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here



--
Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
Reply | Threaded
Open this post in threaded view
|

Re: [Csnd] MIDI controller question

Steven Yi
I've added an issue to the tracker:

https://github.com/csound/csound/issues/928


to track work on adding a warning.  Please do subscribe to the issue
and add feedback there for the design.




On Sun, Feb 11, 2018 at 9:05 AM, Dave Seidel <[hidden email]> wrote:

> I like the idea of deferring to the highest rate in the expression, and glad
> you think the warning is worth considering. It might have saved me a couple
> of hours. :-)
>
> On Sun, Feb 11, 2018 at 9:00 AM, Victor Lazzarini <[hidden email]>
> wrote:
>>
>> I am not sure we have gone systematically looking at the oentry tables to
>> place the highest rate first, but it’s worth deciding the
>> rule and implementing.
>>
>> Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy
>> Maynooth University
>> Ireland
>>
>> On 11 Feb 2018, at 13:53, Steven Yi <[hidden email]> wrote:
>>
>> The out types are taken into account. But we have in the language the
>> ability to define opcodes with the same in args (arity and types) and
>> different out args. And in this case both i- and k-types would be
>> semantically viable for the code in context. It's ambiguous because of this
>> kind of overloading. I thought thiugh we had a rule of highest rate first
>> (which is determined by first match in OENTRY table) but maybe it's the
>> other way (as seen here with ctrl7, but this could be a bug here too...)
>>
>> Anyways, a warning could certainly be added that prints when multiple
>> matching opcodes are found and the default is used. Seems very useful to
>> have.
>>
>> On Sun, Feb 11, 2018, 08:13 Dave Seidel <[hidden email]> wrote:
>>>
>>> Point taken, Victor. This is the part of the new syntax that I keep
>>> forgetting about, because it's just not intuitive. After having spent
>>> several hours trying to figure this out, I wish there was, perhaps, some
>>> level of warnings that could be used to emit warnings on type inferences.
>>> Are there any plans to eventually extend type inference to take the out type
>>> into account?
>>>
>>> On Sun, Feb 11, 2018 at 5:08 AM, Victor Lazzarini
>>> <[hidden email]> wrote:
>>>>
>>>> it’s not a bug. You need to give it a type hint
>>>>
>>>> kvar = ctrl7:k(...)
>>>>
>>>> because otherwise the i-time opcode will be called (there is no out type
>>>> inference in this form).
>>>>
>>>> Victor Lazzarini
>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>> Maynooth University
>>>> Ireland
>>>>
>>>> On 11 Feb 2018, at 02:47, Dave Seidel <[hidden email]> wrote:
>>>>
>>>> Hi Art,
>>>>
>>>> Thanks for jumping in! Figured it out, and the reason was surprising. It
>>>> seems that
>>>>
>>>>     gk1 = ctrl7(2, 103, 0, 1)
>>>>
>>>> does not work the same as
>>>>
>>>>     gk1 ctrl7 2, 103, 0, 1
>>>>
>>>> Specifically, if I use the new functional syntax as in the former
>>>> example (which I prefer), the statement seems to only execute once (at init
>>>> time). But in the latter form (old style), it works exactly as expected.
>>>> There's no conflict between massign and ctrl7.
>>>>
>>>> I will probably write this up as a bug tomorrow.
>>>>
>>>> - Dave
>>>>
>>>> On Sat, Feb 10, 2018 at 7:40 PM, Arthur Hunkins
>>>> <[hidden email]> wrote:
>>>>>
>>>>> Dave -
>>>>>
>>>>> Are you saying that with -M5 (and your UC-16 MIDI device #5), no
>>>>> massigns, your UC-16 outputting on channel 2), your .csd doesn't produce an
>>>>> output with ctrl7 on channel 2 (and of course compatible controller
>>>>> numbers)? This surely doesn't make any sense.
>>>>>
>>>>> That aside, I've three thoughts (all possibly irrelevent):
>>>>> 1) -Ma came somewhat later than midiin and massign. Could something
>>>>> strange be going on in your rather complex setting (maybe showing a
>>>>> limitation of -Ma)?
>>>>> 2) I'm not sure that ctrl7 (which I'm assuming you're using with the
>>>>> UC-16's knobs) responds to massign in the same way that midiin does; indeed
>>>>> I'm not sure that ctrl7 isn't completely independent of massign's assignment
>>>>> to instruments.
>>>>> 3) Could massign, OTOH, be hijacking ctrl7 and forcing it to be
>>>>> assigned as midiin is?
>>>>>
>>>>> I do know that with -Ma, two MIDI controllers on the same channel or on
>>>>> different channels work together properly with ctrl7. I've never tried two
>>>>> control devices with midiin and/or massign though.
>>>>>
>>>>> I've a UC-16 and would be happy to try out a simplified example of
>>>>> yours if it would help.
>>>>>
>>>>> Best -
>>>>>
>>>>> Art H.
>>>>>
>>>>> Art Hunkins
>>>>> http://www.arthunkins.com
>>>>>
>>>>> On Sat, Feb 10, 2018 at 3:27 PM, Dave Seidel <[hidden email]>
>>>>> wrote:
>>>>>>
>>>>>> I am working on a piece that reads input from a MIDI keyboard
>>>>>> (McMillen QuNexus). This is working fine. Now I'd like to also read
>>>>>> controller input from my old Evolution UC-16, which is a bank of knobs. So
>>>>>> far, I'm not getting any data from the UC-16. I've verified with kmidimon
>>>>>> that the UC-16 is working as configured (i.e., channel number and controller
>>>>>> numbers).
>>>>>>
>>>>>> The keyboard is using channel 1. I use massign to bind this channel to
>>>>>> an instrument.
>>>>>>
>>>>>> The UC-16 is using channel 2. I'm using ctrl7 to read the data, just
>>>>>> on one controller so far, but the kvar that it sets never changes value (I'm
>>>>>> using printk2). I've tried using massign two different ways with no success
>>>>>> :
>>>>>>
>>>>>>   massign 2, 0    ; muted
>>>>>>   massign 2, 20  ; assigned to instr 20
>>>>>>
>>>>>> I've also tried not using massign with channel 2 at all, no luck there
>>>>>> either.
>>>>>>
>>>>>> I'm using -Ma, but even if I use -M5 (the UC-16 is device 5), I don't
>>>>>> get any controller data.
>>>>>>
>>>>>> I'm sure I'm doing something wrong, or missing something, but I'm
>>>>>> stumped. Anyone have any ideas how I can get this working?
>>>>>>
>>>>>> Thanks,
>>>>>> Dave
>>>>>>
>>>>>> Csound mailing list [hidden email]
>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>>>>>> https://github.com/csound/csound/issues Discussions of bugs and features can
>>>>>> be posted here
>>>>>
>>>>>
>>>>> Csound mailing list [hidden email]
>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>>>>> https://github.com/csound/csound/issues Discussions of bugs and features can
>>>>> be posted here
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> http://mysterybear.net
>>>> https://soundcloud.com/mysterybear
>>>> https://mysterybear.bandcamp.com
>>>>
>>>> http://recordings.irritablehedgehog.com/album/dave-seidel-60-hz
>>>> Csound mailing list [hidden email]
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>>>> https://github.com/csound/csound/issues Discussions of bugs and features can
>>>> be posted here
>>>>
>>>> Csound mailing list [hidden email]
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>>>> https://github.com/csound/csound/issues Discussions of bugs and features can
>>>> be posted here
>>>
>>>
>>>
>>>
>>> --
>>> http://mysterybear.net
>>> https://soundcloud.com/mysterybear
>>> https://mysterybear.bandcamp.com
>>>
>>> http://recordings.irritablehedgehog.com/album/dave-seidel-60-hz
>>> Csound mailing list [hidden email]
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>>> https://github.com/csound/csound/issues Discussions of bugs and features can
>>> be posted here
>>
>> Csound mailing list [hidden email]
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>> https://github.com/csound/csound/issues Discussions of bugs and features can
>> be posted here
>>
>> Csound mailing list [hidden email]
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>> https://github.com/csound/csound/issues Discussions of bugs and features can
>> be posted here
>
>
>
>
> --
> http://mysterybear.net
> https://soundcloud.com/mysterybear
> https://mysterybear.bandcamp.com
>
> http://recordings.irritablehedgehog.com/album/dave-seidel-60-hz
> Csound mailing list [hidden email]
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
> https://github.com/csound/csound/issues Discussions of bugs and features can
> be posted here

Csound mailing list
[hidden email]
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here