I tried the same patch on MacOSX and Debian and it seems to be a bug on the Linux build : I'm sending the outlet of [f $1] to both a number box and a [print] and in Linux the print returns the right value but the number box stays at 0 (yes sorry for the precedent statement it is not actually empty, it displays 0) but that same patch in MacOSX displays the same value in both the print area and the number box. That's why I thought I wasn't sending the right type to the number box since something was coming out for [print] but not for the number box.

I built this pd extended from CVS about 2 months ago with help from Hans since it's on Linux/PPC and there were some problems. I guess I have to build it again.

and I thought I was going to make music today :) I'm going to buy a guitar...

thanks for your help

derek holzer wrote:

Works here. Try the attached patches. Save both somewhere and load "main.pd". The [bang< message should output $1's value (i.e. "1").

If those don't work for you, you might have some trouble with your number box. In that case, info on your OS, PD version and possibly also your Tcl/Tk versions would be useful, as the problem would be somewhere in there.

d.

AshK wrote:

...

yes that's exactly what I mean and I have tried that already but the number box remains empty.

...

Georg Holzmann wrote:

...

Hallo!

...

I couldn't find it in the doc. I have an abstraction with 2 arguments : [abstraction 1 2], inside the abstraction I send $1 to [print] and it returns 1. That's perfect but instead of the [print] I want a number box. When I try nothing happens. How can I get my variable in a number box?

I don't know if I understand you correct, but maybe you mean this:

[bang( | [f $1] | [numberbox]

LG Georg

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

---

#N canvas 0 22 454 304 10; #X obj 214 90 f $1; #X obj 219 50 inlet; #X obj 211 144 outlet; #X connect 0 0 2 0; #X connect 1 0 0 0;

---

#N canvas 0 22 454 304 10; #X obj 249 128 abst 1 2; #X floatatom 249 177 5 0 0 0 - - -; #X msg 253 91 bang; #X connect 0 0 1 0; #X connect 2 0 0 0;

ok thanks for the advice I'm going to try both. And about the speed it makes no doubt the linux version is incredibly faster; on some patches macosx runs at about 90% of the cpu while linux is at 20%.

derek holzer wrote:

Just as a note... I've been using Miller's version of Pd 0.39 on Gentoo Linux/PPC since last December without any serious problems. In fact, it runs better, faster and more stable than on OSX on the same machine. You might consider compiling that version over the extended version and see if that makes a difference for you. It could be some "extended" aspect of the code which is giving problems rather than core PD or Tcl/Tk.

best, d.

AshK wrote:

...

I tried the same patch on MacOSX and Debian and it seems to be a bug on the Linux build : I'm sending the outlet of [f $1] to both a number box and a [print] and in Linux the print returns the right value but the number box stays at 0 (yes sorry for the precedent statement it is not actually empty, it displays 0) but that same patch in MacOSX displays the same value in both the print area and the number box. That's why I thought I wasn't sending the right type to the number box since something was coming out for [print] but not for the number box.

I built this pd extended from CVS about 2 months ago with help from Hans since it's on Linux/PPC and there were some problems. I guess I have to build it again.

and I thought I was going to make music today :) I'm going to buy a guitar...

On 7/29/06, derek holzer derek@x-i.net wrote:

As far as I can tell, and I've posted on it extensively here in the past, this speed difference is due to the interference of the graphical interface on OSX, and it seems to affect audio-related patches worse than GEM-related ones. The extra layer of Aqua + Tcl/Tk takes far too much resources, and responds very badly under pressure--sometimes simply freezing up as no doubt you've already seen. I suppose this could be dealt with by compiling PD with an X11 version of Tcl/Tk and some other junk, but honestly I've been too busy performing and making sound the last year to try to sort out all of OSX's problems.

But OSX is so sharp-looking! lol I've had many a number-box freeze up on me, and someone here suggested that, if a particular numberbox was important, to use a num2 GUI, from the lower part of the put menu, or Ctl-Shift-n. These always update. However, if you're running a pretty busy patch, best not to put too many of these in there, as they will force everything to wait for the GUI.

On Jul 30, 2006, at 7:51 PM, Mathieu Bouchard wrote:

Speaking of which, I think that Pd looks worse on OSX than on
Linux, mainly due to anti-aliasing. All boxes look blurry and dim.
This is because the anti-aliasing is done without any kerning.
Kerning is the rounding of pixel positions done to minimize the
amount of anti-aliasing required. This is because raw anti-aliasing
always gives that blurry effect that tires the eye.

...it really depends on what tcl/tk version you are using...I believe
the current 8.4.13 is now fully using ATSUI font rendering, which
should solve the anti-aliasing/kerning problems...but, it is a work
in progress, and there aren't alot of eyeballs offering code...

...also wanted to point out that the point size/level at which anti- aliasing kicks in can be set in u_main.tk/pd.tk, around line 52:

 # set minimum line size for anti-aliasing.  If set to 1 or 0,  

then every # line will be anti-aliased. While this makes connections and
circles in # [bng] and such look really good, it makes boxes and messages
look out of # focus. Setting this to 2 makes it so the thick audio rate
connections # are anti-aliased. hans@at.or.at 2005-06-09 set tk::mac::CGAntialiasLimit 2

...feel free to adjust to your preference...

About the speed: Tcl/Tk on OSX includes a fake X11 library which is
a translation layer so that Tk doesn't have to be rewritten for
OSX. That layer shouldn't take much CPU in theory, but I don't know
how it's been implemented. May someone who cares about OSX figure
out why that X11/OSX layer sucks. This problem is distinct from the
superfluous canvas redrawing that happens on all platforms, but the
two problems cumulate to create some kind of disaster.

...true, tk is emulating X11 calls on osx: unfortunately it was
originally done in QuickDraw, which was fine for the time, but really
started to fall to the side around 10.3, when Coregraphics/ATSUI/ Quartz/whatever rendering became "preferred"...It should be well
known that most of the canvas drawing in pd (lines, boxes, text) has
been converted to the newer API's, but there is still a hangup in
that we are now dealing with a tri/quad buffered drawing system!
Back in the day, one of Tk's innovations was double-buffered drawing,
which gave a smooth user experience that was rare for the
time...however, now we still have that behaviour, but also have in
OSX's aqua the entire window system being automatically double
buffered, so in effect we draw way too much! Awhile ago I started to
rip out the offscreen buffering in Tk so that everything was just
drawn directly to the window manager, but it was put on hold until
the ATSUI code was more finalized...

...luckily, we seem to be at a spot for another try, so maybe I can
find some time again...?

jamie

well I keep working on this patch on the working PD and I need help about how I can pass the $3 variable to the second [ctlin] (the one that uses $3 as an argument) ?

see the attached patches (open main, the other is the abstraction)

thanks

derek holzer wrote:

Works here. Try the attached patches. Save both somewhere and load "main.pd". The [bang< message should output $1's value (i.e. "1").

If those don't work for you, you might have some trouble with your number box. In that case, info on your OS, PD version and possibly also your Tcl/Tk versions would be useful, as the problem would be somewhere in there.

d.

AshK wrote:

...

yes that's exactly what I mean and I have tried that already but the number box remains empty.

...

Georg Holzmann wrote:

...

Hallo!

...

I couldn't find it in the doc. I have an abstraction with 2 arguments : [abstraction 1 2], inside the abstraction I send $1 to [print] and it returns 1. That's perfect but instead of the [print] I want a number box. When I try nothing happens. How can I get my variable in a number box?

I don't know if I understand you correct, but maybe you mean this:

[bang( | [f $1] | [numberbox]

LG Georg

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

---

#N canvas 0 22 454 304 10; #X obj 214 90 f $1; #X obj 219 50 inlet; #X obj 211 144 outlet; #X connect 0 0 2 0; #X connect 1 0 0 0;

---

#N canvas 0 22 454 304 10; #X obj 249 128 abst 1 2; #X floatatom 249 177 5 0 0 0 - - -; #X msg 253 91 bang; #X connect 0 0 1 0; #X connect 2 0 0 0;

#N canvas 674 31 273 207 10; #X floatatom 97 111 5 0 0 0 - - -; #X obj 97 58 ctlin14 1 1; #X connect 1 0 0 0;

#N canvas 603 366 579 334 10; #X obj 40 62 f $1; #X msg 37 35 bang; #X obj 16 5 ctlin $1 $2; #X obj 40 85 + 32; #X obj 20 133 ctlin $1 $2; #X obj 19 157 * 128; #X obj 68 230 +; #X obj 131 174 ctlin $3 $2; #X msg 73 197 bang; #X obj 68 254 outlet; #X text 86 36 when the specified MIDI slider is moved it bangs and loads the value of the MIDI parameter + 32 in $3; #X text 115 225 add them and you get 14bits MIDI; #X text 114 131 here you have the MSB (the first 7 bits of the MIDI message); #X text 134 193 and here the LSB (the last 7 bits); #X obj 39 106 f $3; #X connect 0 0 3 0; #X connect 1 0 0 0; #X connect 2 0 1 0; #X connect 3 0 14 0; #X connect 4 0 5 0; #X connect 5 0 6 0; #X connect 6 0 9 0; #X connect 7 0 6 1; #X connect 7 0 8 0; #X connect 8 0 6 0;

Since this abstraction is not working yet I have started to do the math myself the way you mentioned and I realized I'm going to have to bind a *lot* of MIDI parameters and they will often change so I'd like to make this abstraction work and I thought setting a variable was easy.

I was trying to do that "sub" abstraction you are talking about so yes it makes a lot of sense but I didn't succeed so I'm not sure I really get it but if you say it works then I'm going to try again.

thanks

derek holzer wrote:

Well, I see exactly what you are trying to do, but it's not exactly the right way to do it.

In this case, you would have to set the value of $3 external to the abstraction. Since the [ctlin] object doesn't take any inputs, it can only get variables from creation arguments.

If you really wanted to dynamically create this abstraction, which would automatically create the LSB channel of the control in message, you could create another abstraction within the abstraction, and add 32 to the channel number in the first-level abstraction which would pass it as a creation argument to the inner-most abstraction.

Does that make sense?

Otherwise, and probably what I would do, would be to simply create the abstraction you made already with three creation arguments and do the math yourself, i.e. make $3 equal to $1 + 32. Unless you're stubborn and you simply *must* have the computer do all the work for you ;-)

Or maybe you have a more compelling reason why PD should dynamically create these [ctlin]s without you having to think about it...?

best, d.

AshK wrote:

...

well I keep working on this patch on the working PD and I need help about how I can pass the $3 variable to the second [ctlin] (the one that uses $3 as an argument) ?

I forgot one thing, in my patch ctlin.pd with the [+] object the bang is not necessary, it even adds some wrong numbers, I just swaped the the incoming parameters and it makes what I want but a dedicated inlet for the bang would be more user friendly... to me. But I give up trying to create the dynamic stuff, it is way too complicated for me to add a simple variable to an object, I'll do the math myself as you suggested Derek, it's going to take a long time but not as long as what I spent today on this stuff. And doing a long and repetitive task by hand is not really what I thought pd was about.

thanks for your help

Chuckk Hubbard wrote:

How's this? Probably pretty inefficient way to do it, but it works. The test inputs are for if you have a MIDI loop, where output comes back as input to Pd. Otherwise use whatever cc sending device you normally use to check it. I'm sure there's a simpler way... anyone? ctlhouse.pd is the file to open.

-Chuckk

On 7/29/06, derek holzer derek@x-i.net wrote:

...

If you really wanted to dynamically create this abstraction, which would automatically create the LSB channel of the control in message, you could create another abstraction within the abstraction, and add 32 to the channel number in the first-level abstraction which would pass it as a creation argument to the inner-most abstraction.

wow it works and it's simple and it's a better idea to use ctlin without arguments! thanks a lot Chuckk and everybody. Your advices are pretty efficient too, I'm regaining faith in PD :) Well I got some MIDI channels to map now, bye!

Chuckk Hubbard wrote:

Here's a way to do the same thing without any arguments for ctlin. ctlbox.pd is the shell, ctlabst.pd is what is doing the work. As far as I can tell it does exactly what you were looking for.

If you are going to create a whole bunch of abstractions or objects with different arguments, may I suggest you:

1. Put one abstraction/object down
2. Highlight it
3. Press Ctl-D to duplicate it as many times as you need
4. Move the clones wherever you need them to be able to see
5. Save and open the patch in a text editor and change the arguments

that way, where they are all listed one after another. Less clicking that way.

You should be able to see what I'm talking about if you don't know. It's a good thing to understand if you want to be effective with Pd. But I think the abstraction I attached does it too.

-Chuckk

On 7/29/06, AshK ashk@azylum.net wrote:

...

I forgot one thing, in my patch ctlin.pd with the [+] object the bang is not necessary, it even adds some wrong numbers, I just swaped the the incoming parameters and it makes what I want but a dedicated inlet for the bang would be more user friendly... to me. But I give up trying to create the dynamic stuff, it is way too complicated for me to add a simple variable to an object, I'll do the math myself as you suggested Derek, it's going to take a long time but not as long as what I spent today on this stuff. And doing a long and repetitive task by hand is not really what I thought pd was about.

thanks for your help

Yes! exactly what I was thinking, I was trying to understand which one is more efficient, I could see a very little difference if no difference at all with cpu time. By the way I'm going to need the same abstraction for ctlout and I'm going to do it right away.

Chuckk Hubbard wrote:

Glad to hear it. Actually, I'm not sure, it might be more efficient to just have one ctlin, outside of the abstraction, and send the messages to all the filters. I don't know enough about how MIDI works.

On 7/30/06, AshK ashk@azylum.net wrote:

...

wow it works and it's simple and it's a better idea to use ctlin without arguments! thanks a lot Chuckk and everybody. Your advices are pretty efficient too, I'm regaining faith in PD :) Well I got some MIDI channels to map now, bye!

Chuckk Hubbard wrote:

...

Here's a way to do the same thing without any arguments for ctlin. ctlbox.pd is the shell, ctlabst.pd is what is doing the work. As far as I can tell it does exactly what you were looking for.

If you are going to create a whole bunch of abstractions or objects with different arguments, may I suggest you:

1. Put one abstraction/object down
2. Highlight it
3. Press Ctl-D to duplicate it as many times as you need
4. Move the clones wherever you need them to be able to see
5. Save and open the patch in a text editor and change the arguments

that way, where they are all listed one after another. Less clicking that way.

You should be able to see what I'm talking about if you don't know. It's a good thing to understand if you want to be effective with Pd. But I think the abstraction I attached does it too.

-Chuckk

On 7/29/06, AshK ashk@azylum.net wrote:

...

I forgot one thing, in my patch ctlin.pd with the [+] object the

bang is

...

...

not necessary, it even adds some wrong numbers, I just swaped the the incoming parameters and it makes what I want but a dedicated inlet for the bang would be more user friendly... to me. But I give up trying to create the dynamic stuff, it is way too complicated for me to add a simple variable to an object, I'll do the math myself as you suggested Derek, it's going to take a long time but not as long as what I spent today on this stuff. And doing a long and repetitive task by hand is not really what I thought pd was about.

thanks for your help