Hey All,
I don't know if anyone's done this but I've attached a midi learn abstraction I've been working on. The logic's a bit messy but I got it working in the end.
Basically from banging the learn patch it listens to the next signal, either a note or a control signal, and then filters out only the velocity or control value from that. (I've started taking an interest in controlling patches with the velocity, as opposed to the note number).
Let me know what you think, and if you know of anything similar being done.
Cheers
Andrew
Hi Andrew,
I made something similar a couple of weeks ago, as I needed a quick way to map midi controllers. It's only for CC though...
Patrick
On Tue, Aug 3, 2010 at 1:09 PM, Andrew Faraday jbturgid@hotmail.com wrote:
Hey All,
I don't know if anyone's done this but I've attached a midi learn abstraction I've been working on. The logic's a bit messy but I got it working in the end.
Basically from banging the learn patch it listens to the next signal, either a note or a control signal, and then filters out only the velocity or control value from that. (I've started taking an interest in controlling patches with the velocity, as opposed to the note number).
Let me know what you think, and if you know of anything similar being done.
Cheers
Andrew
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I actually prefer your solution to mine, the [==] boxes are exactly what I was looking for and would have saved quite a lot of logic. Also I didn't think of [t a a a] which would have saved quite a lot of time. Will have to keep an eye on these for future work. I've got you in one place, tho. you can use [*] for conditional logic (with a [bang]) to activate when the right inlet changes. instead of multiple spigots. The logic goes, if all of them are 1, the result is 1. If any are 0, the result is zero. Useful stuff. Although more useful when you're working in audio, usually with [expr~] and the inlets of [*~] are summing. I've gone on a bit of a tangent here. Always interested in approaches to logic in pd, tho. Andrew
Date: Wed, 4 Aug 2010 13:20:51 -0400 Subject: Re: [PD] midi learn From: pboivin@gmail.com To: jbturgid@hotmail.com CC: pd-list@iem.at
Hi Andrew,
I made something similar a couple of weeks ago, as I needed a quick way to map midi controllers. It's only for CC though...
Patrick
On Tue, Aug 3, 2010 at 1:09 PM, Andrew Faraday jbturgid@hotmail.com wrote:
Hey All,
I don't know if anyone's done this but I've attached a midi learn abstraction I've been working on. The logic's a bit messy but I got it working in the end.
Basically from banging the learn patch it listens to the next signal, either a note or a control signal, and then filters out only the velocity or control value from that. (I've started taking an interest in controlling patches with the velocity, as opposed to the note number).
Let me know what you think, and if you know of anything similar being done.
Cheers
Andrew
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, Aug 4, 2010 at 6:51 PM, Andrew Faraday jbturgid@hotmail.com wrote:
I've got you in one place, tho. you can use [*] for conditional logic (with a [bang]) to activate when the right inlet changes. instead of multiple spigots.
In that case, you could also replace the first [spigot] with a [&&] taking the values from both [==] and then going into the right inlet of the other [spigot]. I don't think it makes any difference... If you have 3 conditions to verify before passing some data, you will end up with three [spigots] with the first approach, or two [&&] and one [spigot] with the other.
Patrick
hi, I also patched a midi learn abstraction... then I found this discussion and replaced all [select] by [==]... Thank's :-) Hope you'll enjoy this one: both cc and channel values are saved in an external message box with a [set( message in the abstraction itself... so no need to re-learn on each session. Two arguments to scale your 0-127: can be negative numbers or reversed scale. Maybe somebody can help me with that: I didn't found a way to set 0-127 as default. So the two arguments are obligatory... cheers raf
Andrew Faraday a écrit :
I actually prefer your solution to mine, the [==] boxes are exactly what I was looking for and would have saved quite a lot of logic. Also I didn't think of [t a a a] which would have saved quite a lot of time. Will have to keep an eye on these for future work.
I've got you in one place, tho. you can use [*] for conditional logic (with a [bang]) to activate when the right inlet changes. instead of multiple spigots. The logic goes, if all of them are 1, the result is
- If any are 0, the result is zero. Useful stuff. Although more
useful when you're working in audio, usually with [expr~] and the inlets of [*~] are summing.
I've gone on a bit of a tangent here. Always interested in approaches to logic in pd, tho.
Andrew
Date: Wed, 4 Aug 2010 13:20:51 -0400 Subject: Re: [PD] midi learn From: pboivin@gmail.com To: jbturgid@hotmail.com CC: pd-list@iem.at
Hi Andrew,
I made something similar a couple of weeks ago, as I needed a quick way to map midi controllers. It's only for CC though...
Patrick
On Tue, Aug 3, 2010 at 1:09 PM, Andrew Faraday
jbturgid@hotmail.com wrote:
Hey All,
I don't know if anyone's done this but I've attached a midi learn abstraction I've been working on. The logic's a bit messy but I got it working in the end.
Basically from banging the learn patch it listens to the next
signal, either
a note or a control signal, and then filters out only the velocity or control value from that. (I've started taking an interest in
controlling
patches with the velocity, as opposed to the note number).
Let me know what you think, and if you know of anything similar
being done.
Cheers
Andrew
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
#N canvas 192 171 386 238 10; #X obj 37 19 ctlin; #X floatatom 15 45 5 0 0 0 - - -; #X floatatom 50 45 5 0 0 0 - - -; #X floatatom 85 45 5 0 0 0 - - -; #X floatatom 169 105 5 0 0 0 - - -; #X msg 212 60; #X obj 169 29 raf_ctlin 7 333; #X connect 0 0 1 0; #X connect 0 1 2 0; #X connect 0 2 3 0; #X connect 5 0 6 0; #X connect 6 0 4 0; #X connect 6 1 5 0;
#N canvas 178 285 565 559 10; #X obj 50 222 loadbang; #X obj 50 294 -; #X obj 50 318 / 127; #X obj 35 355 *; #X obj 50 246 t b b; #X obj 50 269 f $2; #X obj 86 269 f $1; #X obj 36 378 + $1; #X obj 36 403 outlet; #X obj 195 275 outlet; #X obj 213 240 loadbang; #X obj 80 35 inlet; #X obj 168 132 spigot; #X msg 168 191 set $1 $2; #X obj 35 65 ctlin; #X obj 80 59 unpack; #X obj 35 183 spigot; #X obj 35 120 spigot; #X obj 203 104 tgl 9 0 empty $0-learn empty 17 7 0 10 -24198 -24198 -24198 0 1; #X obj 213 132 spigot; #X obj 168 161 pack f f; #X obj 168 240 t b a; #X obj 168 328 $0; #X msg 168 352 ; $1-learn color 16 16 16; #X obj 286 223 $0; #X msg 286 247 ; $1-learn color 13 13 13; #X obj 314 187 $0; #X msg 314 211 ; $1-learn color 0 0 0; #X obj 286 134 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X obj 286 158 select 1 0; #X obj 286 112 metro 300; #X msg 286 86 stop; #X obj 168 301 t b b; #X obj 68 93 ==; #X obj 48 154 ==; #X connect 0 0 4 0; #X connect 1 0 2 0; #X connect 2 0 3 1; #X connect 3 0 7 0; #X connect 4 0 5 0; #X connect 4 1 6 0; #X connect 5 0 1 0; #X connect 6 0 1 1; #X connect 7 0 8 0; #X connect 10 0 9 0; #X connect 11 0 15 0; #X connect 12 0 20 0; #X connect 13 0 21 0; #X connect 14 0 17 0; #X connect 14 1 12 0; #X connect 14 1 34 0; #X connect 14 2 19 0; #X connect 14 2 33 0; #X connect 15 0 34 1; #X connect 15 1 33 1; #X connect 16 0 3 0; #X connect 17 0 16 0; #X connect 18 0 12 1; #X connect 18 0 19 1; #X connect 18 0 30 0; #X connect 19 0 20 1; #X connect 20 0 13 0; #X connect 21 0 9 0; #X connect 21 0 18 0; #X connect 21 0 32 0; #X connect 21 1 9 0; #X connect 22 0 23 0; #X connect 24 0 25 0; #X connect 26 0 27 0; #X connect 28 0 29 0; #X connect 29 0 24 0; #X connect 29 1 26 0; #X connect 30 0 28 0; #X connect 31 0 30 0; #X connect 32 0 22 0; #X connect 32 1 31 0; #X connect 33 0 17 1; #X connect 34 0 16 1; #X coords 0 -1 1 1 15 15 1 200 100;
I'd go with putting 0 - 127 as creation arguments in your range object. As in:
[range 0 127 0 127]
Then have two fixed variable boxes with your abstraction arguments
[$1], [$2] witha loadbang being fed into them and then to the right two inlets of your range object.
I'm not entirely sure, but if there's no creation argument for your abstraction this will probably not output a float on the loadbang. (I'd have to check this and don't have time to right now). Best guess would be it will throw a couple of errors but won't change the arguments for range. Therefore defaulting to 0 - 127 if the arguments aren't set.
Do let me know if this helps.
Andrew
Date: Mon, 20 Sep 2010 14:54:58 +0200 From: rafael.raccuia@blindekinder.com To: jbturgid@hotmail.com CC: pboivin@gmail.com; pd-list@iem.at Subject: Re: [PD] midi learn
hi,
I also patched a midi learn abstraction... then I found this discussion and replaced all [select] by [==]... Thank's :-)
Hope you'll enjoy this one: both cc and channel values are saved in an external message box with a [set( message in the abstraction itself... so no need to re-learn on each session. Two arguments to scale your 0-127: can be negative numbers or reversed scale.
Maybe somebody can help me with that: I didn't found a way to set 0-127 as default. So the two arguments are obligatory...
cheers
raf
Andrew Faraday a écrit :
I actually prefer your solution to mine, the [==] boxes are exactly what I was looking for and would have saved quite a lot of logic. Also I didn't think of [t a a a] which would have saved quite a lot of time. Will have to keep an eye on these for future work.
I've got you in one place, tho. you can use [*] for conditional logic (with a [bang]) to activate when the right inlet changes. instead of multiple spigots. The logic goes, if all of them are 1, the result is 1. If any are 0, the result is zero. Useful stuff. Although more useful when you're working in audio, usually with [expr~] and the inlets of [*~] are summing.
I've gone on a bit of a tangent here. Always interested in approaches to logic in pd, tho.
Andrew
Date: Wed, 4 Aug 2010 13:20:51 -0400
Subject: Re: [PD] midi learn
From: pboivin@gmail.com
To: jbturgid@hotmail.com
CC: pd-list@iem.at
Hi Andrew,
I made something similar a couple of weeks ago, as I needed a quick
way to map midi controllers. It's only for CC though...
Patrick
On Tue, Aug 3, 2010 at 1:09 PM, Andrew Faraday
jbturgid@hotmail.com wrote:
Hey All,
I don't know if anyone's done this but I've attached a midi
learn
abstraction I've been working on. The logic's a bit messy but
I got it
working in the end.
Basically from banging the learn patch it listens to the next
signal, either
a note or a control signal, and then filters out only the
velocity or
control value from that. (I've started taking an interest in
controlling
patches with the velocity, as opposed to the note number).
Let me know what you think, and if you know of anything
similar being done.
Cheers
Andrew
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
hey I've put together a little abstraction (attached) to demonstrate the defaulting I mentioned earlier. Either give it no arguments for the range object to output 0 to 127 or set your top and bottom range with this. Unfortunately without arguments the fixed variable boxes stuck on zero, I've added some conditional logic so this will work unless you set the second argument as 0. Then it will default to 127. Either way, hope this helps. Andrew
Date: Mon, 20 Sep 2010 14:54:58 +0200 From: rafael.raccuia@blindekinder.com To: jbturgid@hotmail.com CC: pboivin@gmail.com; pd-list@iem.at Subject: Re: [PD] midi learn
hi,
I also patched a midi learn abstraction... then I found this discussion and replaced all [select] by [==]... Thank's :-)
Hope you'll enjoy this one: both cc and channel values are saved in an external message box with a [set( message in the abstraction itself... so no need to re-learn on each session. Two arguments to scale your 0-127: can be negative numbers or reversed scale.
Maybe somebody can help me with that: I didn't found a way to set 0-127 as default. So the two arguments are obligatory...
cheers
raf
Andrew Faraday a écrit :
I actually prefer your solution to mine, the [==] boxes are exactly what I was looking for and would have saved quite a lot of logic. Also I didn't think of [t a a a] which would have saved quite a lot of time. Will have to keep an eye on these for future work.
I've got you in one place, tho. you can use [*] for conditional logic (with a [bang]) to activate when the right inlet changes. instead of multiple spigots. The logic goes, if all of them are 1, the result is 1. If any are 0, the result is zero. Useful stuff. Although more useful when you're working in audio, usually with [expr~] and the inlets of [*~] are summing.
I've gone on a bit of a tangent here. Always interested in approaches to logic in pd, tho.
Andrew
Date: Wed, 4 Aug 2010 13:20:51 -0400
Subject: Re: [PD] midi learn
From: pboivin@gmail.com
To: jbturgid@hotmail.com
CC: pd-list@iem.at
Hi Andrew,
I made something similar a couple of weeks ago, as I needed a quick
way to map midi controllers. It's only for CC though...
Patrick
On Tue, Aug 3, 2010 at 1:09 PM, Andrew Faraday
jbturgid@hotmail.com wrote:
Hey All,
I don't know if anyone's done this but I've attached a midi
learn
abstraction I've been working on. The logic's a bit messy but
I got it
working in the end.
Basically from banging the learn patch it listens to the next
signal, either
a note or a control signal, and then filters out only the
velocity or
control value from that. (I've started taking an interest in
controlling
patches with the velocity, as opposed to the note number).
Let me know what you think, and if you know of anything
similar being done.
Cheers
Andrew
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Thank's for that, I thing I'll stay without defaults the moment, but I'll remember this approach. I added a 'bang' option, so object outputs a bang instead of a value for non-zero midi value, for use with a button. The list now has a third item, 0 or 1, to indicate if it's enabled or not... cheers, r
Le lundi 20 septembre 2010 à 20:37 +0100, Andrew Faraday a écrit :
hey
I've put together a little abstraction (attached) to demonstrate the defaulting I mentioned earlier. Either give it no arguments for the range object to output 0 to 127 or set your top and bottom range with this. Unfortunately without arguments the fixed variable boxes stuck on zero, I've added some conditional logic so this will work unless you set the second argument as 0. Then it will default to 127. Either way, hope this helps.
Andrew
Date: Mon, 20 Sep 2010 14:54:58 +0200 From: rafael.raccuia@blindekinder.com To: jbturgid@hotmail.com CC: pboivin@gmail.com; pd-list@iem.at Subject: Re: [PD] midi learn
hi, I also patched a midi learn abstraction... then I found this discussion and replaced all [select] by [==]... Thank's :-) Hope you'll enjoy this one: both cc and channel values are saved in an external message box with a [set( message in the abstraction itself... so no need to re-learn on each session. Two arguments to scale your 0-127: can be negative numbers or reversed scale. Maybe somebody can help me with that: I didn't found a way to set 0-127 as default. So the two arguments are obligatory... cheers raf
Andrew Faraday a écrit : I actually prefer your solution to mine, the [==] boxes are exactly what I was looking for and would have saved quite a lot of logic. Also I didn't think of [t a a a] which would have saved quite a lot of time. Will have to keep an eye on these for future work.
I've got you in one place, tho. you can use [*] for conditional logic (with a [bang]) to activate when the right inlet changes. instead of multiple spigots. The logic goes, if all of them are 1, the result is 1. If any are 0, the result is zero. Useful stuff. Although more useful when you're working in audio, usually with [expr~] and the inlets of [*~] are summing. I've gone on a bit of a tangent here. Always interested in approaches to logic in pd, tho. Andrew > Date: Wed, 4 Aug 2010 13:20:51 -0400 > Subject: Re: [PD] midi learn > From: pboivin@gmail.com > To: jbturgid@hotmail.com > CC: pd-list@iem.at > > Hi Andrew, > > I made something similar a couple of weeks ago, as I needed a quick > way to map midi controllers. It's only for CC though... > > > Patrick > > > On Tue, Aug 3, 2010 at 1:09 PM, Andrew Faraday <jbturgid@hotmail.com> wrote: > > Hey All, > > > > I don't know if anyone's done this but I've attached a midi learn > > abstraction I've been working on. The logic's a bit messy but I got it > > working in the end. > > > > Basically from banging the learn patch it listens to the next signal, either > > a note or a control signal, and then filters out only the velocity or > > control value from that. (I've started taking an interest in controlling > > patches with the velocity, as opposed to the note number). > > > > Let me know what you think, and if you know of anything similar being done. > > > > Cheers > > > > Andrew > > > > _______________________________________________ > > Pd-list@iem.at mailing list > > UNSUBSCRIBE and account-management -> > > http://lists.puredata.info/listinfo/pd-list > > > > ______________________________________________________________ _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Andrew Faraday -
Patrick Boivin -
Raphael Raccuia