hi this is my first patch so bear with my n00bness I ve taken a screen shot of the whole thing open: it s a GEM patch that will show 8 "knobs" and rotate them depending on the MIDI cc input. and also show the cc value. So far i ve created the 8 knobs but i can t really understand how to send the MIDI cc from "handson2" to the abstraction "handson" and parse it to the right knob. Thanks Simone
hi, please send the pd-patch. you can use send/receive in combination with dollararguments inside your abstractions. the dollararguments ($1 $2 $3 $4...) will be substituted with the arguments you give to your abstraction. for example, if your abstraction is called myknob, and you create it like [myknob 99] then every $1 will be given the value 99 [r $1-data] will then receive messages that are sent to '99-data' in that way you can do something like [s 1-knob], [s 2-knob], [s 3-knob] in your parent patch, and have abstractions [myknob 1], [myknob 2], [myknob 3]. inside the myknob abstraction you need [r $1-knob] which will receive individual messages. marius.
simone-www.io-sound.org wrote:
hi this is my first patch so bear with my n00bness I ve taken a screen shot of the whole thing open: it s a GEM patch that will show 8 "knobs" and rotate them depending on the MIDI cc input. and also show the cc value. So far i ve created the 8 knobs but i can t really understand how to send the MIDI cc from "handson2" to the abstraction "handson" and parse it to the right knob. Thanks Simone
simone-www.io-sound.org wrote:
hi this is my first patch so bear with my n00bness I ve taken a screen shot of the whole thing open:
I guess you missed an attachment, or it was too big, or something...
it s a GEM patch that will show 8 "knobs" and rotate them depending on the MIDI cc input. and also show the cc value. So far i ve created the 8 knobs but i can t really understand how to send the MIDI cc from "handson2" to the abstraction "handson" and parse it to the right knob.
Some objects that might be useful:
[route]
[list prepend]
[list trim]
[pack]
[unpack]
I like the following idiom in abstractions:
[inlet] | [route $1] | | | [outlet] // pass through everything not for us | message for us
Then you can do something like:
"foo 1, bar 23, baz 99" | [abs foo] | [abs bar] | [abs baz] | ...
Hopefully these hints are enough,
Claude
On Wed, Sep 3, 2008 at 9:43 PM, Claude Heiland-Allen claudiusmaximus@goto10.org wrote:
simone-www.io-sound.org wrote:
hi this is my first patch so bear with my n00bness I ve taken a screen shot of the whole thing open:
I guess you missed an attachment, or it was too big, or something...
heh yes sorry here it is http://img115.imageshack.us/my.php?image=handsonzq0.png
it s a GEM patch that will show 8 "knobs" and rotate them depending on the MIDI cc input. and also show the cc value. So far i ve created the 8 knobs but i can t really understand how to send the MIDI cc from "handson2" to the abstraction "handson" and parse it to the right knob.
Some objects that might be useful:
[route]
[list prepend]
[list trim]
[pack]
[unpack]
I like the following idiom in abstractions:
[inlet] | [route $1] | | | [outlet] // pass through everything not for us | message for us
Then you can do something like:
"foo 1, bar 23, baz 99" | [abs foo] | [abs bar] | [abs baz] | ...
Hopefully these hints are enough,
Claude
Hi Simone,
I'm guessing that the slider which is attached to the [ctlin] in the parent patch sends to [handson] abstraction. In the future, it's usually better to zip up the whole patch that you have questions about, rather than send a screen shot with potentially hidden information.
But to answer your question: there's no real need to make two levels of abstractions here. Replace the two inlets in [handson] with [f $1] and [f $2] connected to a loadbang. And replace the slider with [ctlin $3 $4].
Then you can replace [handson1 -11 0] with [handson -11 0 80 1]. The CC you mention is actually two values, as in [ctlin 80 1] that must be parsed before the actual controller data will come through.
The other way to do it would be to make a [send CC1], [send CC2], etc etc below the [ctlin] objects, and include a [receive $1] in each [handson] abstraction, in which case you could create it as [handson -11 0 CC1].
Of course, the other suggestions in this thread are also useful, but in a more general way ;-)
best! d.
simone-www.io-sound.org wrote:
hi this is my first patch so bear with my n00bness I ve taken a screen shot of the whole thing open: it s a GEM patch that will show 8 "knobs" and rotate them depending on the MIDI cc input. and also show the cc value. So far i ve created the 8 knobs but i can t really understand how to send the MIDI cc from "handson2" to the abstraction "handson" and parse it to the right knob. Thanks Simone
On Wed, Sep 3, 2008 at 10:55 PM, Derek Holzer derek@umatic.nl wrote:
Hi Simone,
I'm guessing that the slider which is attached to the [ctlin] in the parent patch sends to [handson] abstraction. In the future, it's usually better to zip up the whole patch that you have questions about, rather than send a screen shot with potentially hidden information.
there is a 13Mb font file in the whole thing so i was worried about size.Hey now that i come to think about it, can t <text2d> retrieve fonts from the system assumong i enter the path on PD preferences?
But to answer your question: there's no real need to make two levels of abstractions here. Replace the two inlets in [handson] with [f $1] and [f $2] connected to a loadbang. And replace the slider with [ctlin $3 $4].
yeah i actually knew that but couldn t really figure out how to do it
Then you can replace [handson1 -11 0] with [handson -11 0 80 1]. The CC you mention is actually two values, as in [ctlin 80 1] that must be parsed before the actual controller data will come through.
ok back to PD, and thanks toeverybody for the support
The other way to do it would be to make a [send CC1], [send CC2], etc etc below the [ctlin] objects, and include a [receive $1] in each [handson] abstraction, in which case you could create it as [handson -11 0 CC1].
Of course, the other suggestions in this thread are also useful, but in a more general way ;-)
best! d.
simone-www.io-sound.org wrote:
hi this is my first patch so bear with my n00bness I ve taken a screen shot of the whole thing open: it s a GEM patch that will show 8 "knobs" and rotate them depending on the MIDI cc input. and also show the cc value. So far i ve created the 8 knobs but i can t really understand how to send the MIDI cc from "handson2" to the abstraction "handson" and parse it to the right knob. Thanks Simone
-- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 125: "Only a part, not the whole"
simone-www.io-sound.org wrote:
Hey now that i come to think about it, can t <text2d> retrieve fonts from the system assumong i enter the path on PD preferences?
That's the way paths should work, yes!
d.
hi I hope it s fine with top posting but the issue now is drifting off-topic: the patch works as a charm now, thanks again, but (there is always a but) somehow the incoming MIDI messages are slowed down. I tried to monitor the MIDI in and can see how when i turn the rendering on all the MIDI income gets slowed down terribly. Is there any known issue with GEM and MIDI or anything i have to check on my machine? GEM+sending messages from within PD worked flawlessly, CPU is not hogged, jack runs smoothly. I am attaching the patch but without the font file generating the 7bit midi value
On Wed, Sep 3, 2008 at 11:05 PM, simone-www. io-sound. org cimo75@gmail.com wrote:
On Wed, Sep 3, 2008 at 10:55 PM, Derek Holzer derek@umatic.nl wrote:
Hi Simone,
I'm guessing that the slider which is attached to the [ctlin] in the parent patch sends to [handson] abstraction. In the future, it's usually better to zip up the whole patch that you have questions about, rather than send a screen shot with potentially hidden information.
there is a 13Mb font file in the whole thing so i was worried about size.Hey now that i come to think about it, can t <text2d> retrieve fonts from the system assumong i enter the path on PD preferences?
But to answer your question: there's no real need to make two levels of abstractions here. Replace the two inlets in [handson] with [f $1] and [f $2] connected to a loadbang. And replace the slider with [ctlin $3 $4].
yeah i actually knew that but couldn t really figure out how to do it
Then you can replace [handson1 -11 0] with [handson -11 0 80 1]. The CC you mention is actually two values, as in [ctlin 80 1] that must be parsed before the actual controller data will come through.
ok back to PD, and thanks toeverybody for the support
The other way to do it would be to make a [send CC1], [send CC2], etc etc below the [ctlin] objects, and include a [receive $1] in each [handson] abstraction, in which case you could create it as [handson -11 0 CC1].
Of course, the other suggestions in this thread are also useful, but in a more general way ;-)
best! d.
simone-www.io-sound.org wrote:
hi this is my first patch so bear with my n00bness I ve taken a screen shot of the whole thing open: it s a GEM patch that will show 8 "knobs" and rotate them depending on the MIDI cc input. and also show the cc value. So far i ve created the 8 knobs but i can t really understand how to send the MIDI cc from "handson2" to the abstraction "handson" and parse it to the right knob. Thanks Simone
-- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 125: "Only a part, not the whole"
-- .wmv , .wma , .pps along with all proprietary Windows formats won t be accepted and/or viewed....
Hey Simone,
the only thing I see in the patch is that you should remove the number box inline in the "MIDI to DEGREES" section. Inline GUI elements can slow down a patch, especially when visible. Also, do you really want the CC input to change the size of the font in the [text2d], because that's what it does now ;-)
Besides that, you may want to have a look at your system config. Linux, right? In that case, you should make sure that OpenGL is configured properly, and that you have 3d acceleration enabled, otherwise all the GEM stuff will be done by the CPU which could also slow things down a little or a lot. There's plenty of docs online for whatever distro you are using...
Also, try not to run GEM stuff in the same PD patch as audio stuff (I mentioned this during the workshop). Running separate instances of PD, one for audio and one for GEM, connected with [netsend] objects or OSC, should do the trick.
best! d.
simone-www.io-lab.org wrote:
hi I hope it s fine with top posting but the issue now is drifting off-topic: the patch works as a charm now, thanks again, but (there is always a but) somehow the incoming MIDI messages are slowed down. I tried to monitor the MIDI in and can see how when i turn the rendering on all the MIDI income gets slowed down terribly. Is there any known issue with GEM and MIDI or anything i have to check on my machine? GEM+sending messages from within PD worked flawlessly, CPU is not hogged, jack runs smoothly. I am attaching the patch but without the font file generating the 7bit midi value
Yes, it's better to use two instances of PD when you have GEM and
audio stuff. But here i think there is no problem because you have
not any sound object.
As write Derek, the problem could come from your number box, but it
is not sure.
Maybe you can also use [text3d] instead [text2d].
++
Jack
Le 4 sept. 08 à 00:31, Derek Holzer a écrit :
Hey Simone,
the only thing I see in the patch is that you should remove the number box inline in the "MIDI to DEGREES" section. Inline GUI elements can slow down a patch, especially when visible. Also, do you really
want the CC input to change the size of the font in the [text2d], because
that's what it does now ;-)Besides that, you may want to have a look at your system config.
Linux, right? In that case, you should make sure that OpenGL is configured properly, and that you have 3d acceleration enabled, otherwise all the GEM stuff will be done by the CPU which could also slow things down a little or a lot. There's plenty of docs online for whatever distro you are using...Also, try not to run GEM stuff in the same PD patch as audio stuff (I mentioned this during the workshop). Running separate instances of PD, one for audio and one for GEM, connected with [netsend] objects or
OSC, should do the trick.best! d.
simone-www.io-lab.org wrote:
hi I hope it s fine with top posting but the issue now is drifting
off-topic: the patch works as a charm now, thanks again, but (there is always a but) somehow the incoming MIDI messages are slowed down. I tried to monitor the MIDI in and can see how when i turn the rendering on all the MIDI income gets slowed down terribly. Is there any known issue with GEM and MIDI or anything i have to
check on my machine? GEM+sending messages from within PD worked flawlessly, CPU is not hogged, jack runs smoothly. I am attaching the patch but without the font file generating the
7bit midi value-- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/ macumbista ---Oblique Strategy # 49: "Display your talent"
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
On Thu, Sep 4, 2008 at 12:31 AM, Derek Holzer derek@umatic.nl wrote:
Hey Simone,
the only thing I see in the patch is that you should remove the number box inline in the "MIDI to DEGREES" section. Inline GUI elements can slow down a patch, especially when visible. Also, do you really want the CC input to change the size of the font in the [text2d], because that's what it does now ;-)
no it sends a 7bit value to be displayed, the font size is the second inlet
Besides that, you may want to have a look at your system config. Linux, right? In that case, you should make sure that OpenGL is configured properly, and that you have 3d acceleration enabled, otherwise all the GEM stuff will be done by the CPU which could also slow things down a little or a lot. There's plenty of docs online for whatever distro you are using...
ah! since i got dual head installed i had to say good bye to Compiz and friends, and that maybe means no OpenGL.This is due to xinerama not supporting it, probably i ll have to use xrandr with a virtual desktop size on xorg.conf cause life without dual head can be pretty miserable ;) Yet i don understand why this happens only with midi in and not in other situations.. btw i can t find proper infos about how to offset gemwin on a second screen or to have it not showing bars and window frame Tech specs: Dell D410 1,73Ghz 1,25 Mb Fedora Core 8 + CCRMA rt kernel microkontol KORG
Also, try not to run GEM stuff in the same PD patch as audio stuff (I mentioned this during the workshop). Running separate instances of PD, one for audio and one for GEM, connected with [netsend] objects or OSC, should do the trick.
best! d.
simone-www.io-lab.org wrote:
hi I hope it s fine with top posting but the issue now is drifting off-topic: the patch works as a charm now, thanks again, but (there is always a but) somehow the incoming MIDI messages are slowed down. I tried to monitor the MIDI in and can see how when i turn the rendering on all the MIDI income gets slowed down terribly. Is there any known issue with GEM and MIDI or anything i have to check on my machine? GEM+sending messages from within PD worked flawlessly, CPU is not hogged, jack runs smoothly. I am attaching the patch but without the font file generating the 7bit midi value
-- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 49: "Display your talent"
If you look at the help file for [gemwin], there is a subpatch called "properties" or something similar. Open that and you'll find all the info you need.
d.
simone-www.io-lab.org wrote:
btw i can t find proper infos about how to offset gemwin on a second screen or to have it not showing bars and window frame
On Thu, Sep 4, 2008 at 1:13 AM, simone-www. io-lab. org cimo75@gmail.com wrote:
On Thu, Sep 4, 2008 at 12:31 AM, Derek Holzer derek@umatic.nl wrote:
Hey Simone,
the only thing I see in the patch is that you should remove the number box inline in the "MIDI to DEGREES" section. Inline GUI elements can slow down a patch, especially when visible. Also, do you really want the CC input to change the size of the font in the [text2d], because that's what it does now ;-)
no it sends a 7bit value to be displayed, the font size is the second inlet
Besides that, you may want to have a look at your system config. Linux, right? In that case, you should make sure that OpenGL is configured properly, and that you have 3d acceleration enabled, otherwise all the GEM stuff will be done by the CPU which could also slow things down a little or a lot. There's plenty of docs online for whatever distro you are using...
ah! since i got dual head installed i had to say good bye to Compiz and friends, and that maybe means no OpenGL.This is due to xinerama not supporting it, probably i ll have to use xrandr with a virtual desktop size on xorg.conf cause life without dual head can be pretty miserable ;) Yet i don understand why this happens only with midi in and not in other situations.. btw i can t find proper infos about how to offset gemwin on a second screen or to have it not showing bars and window frame Tech specs: Dell D410 1,73Ghz 1,25 Mb Fedora Core 8 + CCRMA rt kernel microkontol KORG
here we go, this issue with OpenGL has finally pushed me to trash my old Cinerama xorg.conf and go for the newest Xrandr which is just awesome and i have OpenGL on both screens and the patch loads on my external screen and it runs much more smoothly and nicely!! thumbs up !! yet: the response from the MIDI input is not as fast as as i imagined: what does it make it go so slow? Rotating images shouldn t be such a big deal and since i plan to embed this application on a small miniATX computer or similar i wonder what can be done to address this timing issue.. Simone
Also, try not to run GEM stuff in the same PD patch as audio stuff (I mentioned this during the workshop). Running separate instances of PD, one for audio and one for GEM, connected with [netsend] objects or OSC, should do the trick.
best! d.
simone-www.io-lab.org wrote:
hi I hope it s fine with top posting but the issue now is drifting off-topic: the patch works as a charm now, thanks again, but (there is always a but) somehow the incoming MIDI messages are slowed down. I tried to monitor the MIDI in and can see how when i turn the rendering on all the MIDI income gets slowed down terribly. Is there any known issue with GEM and MIDI or anything i have to check on my machine? GEM+sending messages from within PD worked flawlessly, CPU is not hogged, jack runs smoothly. I am attaching the patch but without the font file generating the 7bit midi value
-- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 49: "Display your talent"
-- .wmv , .wma , .pps along with all proprietary Windows formats won t be accepted and/or viewed....
On Fri, Sep 5, 2008 at 12:05 AM, simone-www. io-lab. org cimo75@gmail.com wrote:
On Thu, Sep 4, 2008 at 1:13 AM, simone-www. io-lab. org cimo75@gmail.com wrote:
On Thu, Sep 4, 2008 at 12:31 AM, Derek Holzer derek@umatic.nl wrote:
Hey Simone,
the only thing I see in the patch is that you should remove the number box inline in the "MIDI to DEGREES" section. Inline GUI elements can slow down a patch, especially when visible. Also, do you really want the CC input to change the size of the font in the [text2d], because that's what it does now ;-)
no it sends a 7bit value to be displayed, the font size is the second inlet
Besides that, you may want to have a look at your system config. Linux, right? In that case, you should make sure that OpenGL is configured properly, and that you have 3d acceleration enabled, otherwise all the GEM stuff will be done by the CPU which could also slow things down a little or a lot. There's plenty of docs online for whatever distro you are using...
ah! since i got dual head installed i had to say good bye to Compiz and friends, and that maybe means no OpenGL.This is due to xinerama not supporting it, probably i ll have to use xrandr with a virtual desktop size on xorg.conf cause life without dual head can be pretty miserable ;) Yet i don understand why this happens only with midi in and not in other situations.. btw i can t find proper infos about how to offset gemwin on a second screen or to have it not showing bars and window frame Tech specs: Dell D410 1,73Ghz 1,25 Mb Fedora Core 8 + CCRMA rt kernel microkontol KORG
here we go, this issue with OpenGL has finally pushed me to trash my old Cinerama xorg.conf and go for the newest Xrandr which is just awesome and i have OpenGL on both screens and the patch loads on my external screen and it runs much more smoothly and nicely!! thumbs up !! yet: the response from the MIDI input is not as fast as as i imagined: what does it make it go so slow? Rotating images shouldn t be such a big deal and since i plan to embed this application on a small miniATX computer or similar i wonder what can be done to address this timing issue.. Simone
The issue seems to be gone although it came back once again so i am trying to figure out what slows down the patch.I ll post as soon as i manage to address it. I would like to thank everybody for the support, i am really freaking out with the amazing possibilities such an application can offer.
Also, try not to run GEM stuff in the same PD patch as audio stuff (I mentioned this during the workshop). Running separate instances of PD, one for audio and one for GEM, connected with [netsend] objects or OSC, should do the trick.
best! d.
simone-www.io-lab.org wrote:
hi I hope it s fine with top posting but the issue now is drifting off-topic: the patch works as a charm now, thanks again, but (there is always a but) somehow the incoming MIDI messages are slowed down. I tried to monitor the MIDI in and can see how when i turn the rendering on all the MIDI income gets slowed down terribly. Is there any known issue with GEM and MIDI or anything i have to check on my machine? GEM+sending messages from within PD worked flawlessly, CPU is not hogged, jack runs smoothly. I am attaching the patch but without the font file generating the 7bit midi value
-- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 49: "Display your talent"
-- .wmv , .wma , .pps along with all proprietary Windows formats won t be accepted and/or viewed....
-- .wmv , .wma , .pps along with all proprietary Windows formats won t be accepted and/or viewed....
Otherwise, in case my last email doesn't improve things, more info on your OS, system, MIDI interface, hardware, etc etc might be useful...
d.
simone-www.io-lab.org wrote:
hi I hope it s fine with top posting but the issue now is drifting off-topic: the patch works as a charm now, thanks again, but (there is always a but) somehow the incoming MIDI messages are slowed down. I tried to monitor the MIDI in and can see how when i turn the rendering on all the MIDI income gets slowed down terribly. Is there any known issue with GEM and MIDI or anything i have to check on my machine? GEM+sending messages from within PD worked flawlessly, CPU is not hogged, jack runs smoothly. I am attaching the patch but without the font file generating the 7bit midi value
Last thing, maybe replace the [loadbang] connected directly to the [gemhead] objects with a [loadbang] connected to a "1" message to turn on rendering instead of force it (see helpfile for [gemhead]).
best, d.
simone-www.io-lab.org wrote:
hi I hope it s fine with top posting but the issue now is drifting off-topic: the patch works as a charm now, thanks again, but (there is always a but) somehow the incoming MIDI messages are slowed down. I tried to monitor the MIDI in and can see how when i turn the rendering on all the MIDI income gets slowed down terribly. Is there any known issue with GEM and MIDI or anything i have to check on my machine? GEM+sending messages from within PD worked flawlessly, CPU is not hogged, jack runs smoothly. I am attaching the patch but without the font file generating the 7bit midi value
-
Claude Heiland-Allen -
Derek Holzer -
Jack -
marius schebella -
simone-www.io-lab.org -
simone-www.io-sound.org