On Sat, Nov 20, 2010 at 9:20 PM, Ivica Ico Bukvic ico@vt.edu wrote:

...

The source tarball also includes prebuilt binaries, so assuming you have an intel machine with Ubuntu 9.10, it should "just run." (cd pd/bin/ followed by ./pd). Otherwise, you may have to rebuild it (standard pd-extended 0.42.x procedure).

On Sun, Nov 21, 2010 at 6:50 AM, ALAN BROOKER alan.brooker2010@gmail.com wrote:

Hi Ico,

I'm on Ubuntu and have tried to ./configure but the terminal reports no tk library found :

<snip>

I also had trouble with the tk dependency. When I tried to run the pre-built binary in the tarball it said it couldn't find libtk8.5.so.0, even though it is present in /usr/lib. I'm running Ubuntu Maverick.

-spencer

Also, forgot to mention in my original email this version AFAIK fixes all graph-on-parent bugs.

Just remembered a few more that some of you might find useful:

*send to back/bring to front right-click menu for those of you interested in building more complex UIs *auto-update of scrollbars when typing/resizing objects *canvas always tries to fit the entire patch as best as it can (it is not any more 0,0 coord-centric, however, so it will not reopen patches the way they may have looked in the vanilla-version of pd) *text editing has ctrl+home and ctrl+end traversal between space-delimited words *"select all" is context sensitive (so when editing an object select all will select all its text rather than all objects on the canvas) *select/cut/copy/paste is universal (works seamlessly across text fields and canvas) *commands are ignored in contexts where they have no purpose (e.g. create an object shortcut invoked on the main canvas should have no effect) *improved accuracy of canvas reporting it has been changed

Cheers!

Best wishes,

Ico

Since there are prebuilt binaries and therefore platform-specific configs, probably the safest thing you need to do to rebuild on your platform from scratch is to do the following:

cd pd/src make distclean aclocal autoconf ./configure (with flags you wish to use, typically --prefix=/usr --enable-jack --enable-alsa) make cp pd.tk ../bin (old stale one crept into the tarball inside the bin directory--I will fix this shortly and reupload the tarball)

at that point you can either: cd ../bin ./pd

or (if you feel like this version is worthy being installed system-wide) make install pd

NB: pre-built binaries are for i386 arch only so they are unlikely to work on other (e.g. 64-bit Linux).

As for swapping pd.tk alone, this won't work as pd.tk depends on changes to the source as well.

Finally, regarding the scrolling algorithm, the new version updates scrollbars once a key has been released or mouse has stopped dragging. This is because on an Atom netbook (what we use in L2Ork) things got bogged down quite quickly when using continual scrollbar updates. If you wish to try that one out (it also uses old object moving code via "coords" call which is a lot less efficient) simply download the 20101117 version (replace 20101120 in the URL of the current one).

HTH

Best wishes,

Ico

On Sun, 2010-11-21 at 11:50 +0000, ALAN BROOKER wrote:

Hi Ico,

I'm on Ubuntu and have tried to ./configure but the terminal reports no tk library found :

checking for tcl8.4/tcl.h... yes

checking for main in -ltcl85... no

checking for main in -ltcl8.5... no

checking for main in -ltcl84... no

checking for main in -ltcl8.4... yes

checking for main in -ltk85... no

checking for main in -ltk8.5... no

checking for main in -ltk84... no

checking for main in -ltk8.4... no

checking for main in -ltk8.3... no

checking for main in -ltk8.2... no

checking for main in -ltk8.0... no

no tk library found

and further make errors:

ldl -lm -lpthread -lasound

/usr/bin/ld: cannot find -lasound

collect2: ld returned 1 exit status

make: *** [../bin/pd] Error 1

Still wanting to check it out I swapped the pd-extended pd.tk file with the one from L2Ork pd.tk file and I am getting the following errors on a pop up:

can't read "mult": no such variable

can't read "mult": no such variable

while executing

"expr int($height / ($mult * 2))"

("text" arm line 36)

invoked from within

"switch -exact [$name type $item] {

"arc" -

"line" -

"oval" -

"polygon" -

"rectangle" {

set coords [$name coords $item]

foreach ..."

(procedure "pdtk_canvas_getscroll" line 38)

invoked from within

"pdtk_canvas_getscroll $name"

(procedure "pdtk_canvas_getscroll_ping" line 9)

invoked from within

"pdtk_canvas_getscroll_ping .xa5b7038.c"

("after" script)

And sometimes there are no up scrolling bars

But I wish to say the improvements to the gui on Ubuntu are really nice! Really want to use this from now on- the larger “cord/wire connect” icon is really useful- and appreciate any feedback regarding the above

Cheers

Al

On Sat, Nov 20, 2010 at 9:20 PM, Ivica Ico Bukvic ico@vt.edu wrote: Dear fellow Pd enthusiasts,

    I am pleased to report that earlier today L2Ork released
    latest snapshot
    of its own variation of pd-extended 0.42.5. While we are
    working hard on
    submitting isolated patches upstream (some of which have been
    already
    submitted), many more need to be isolated before they can be
    provided in
    a useful format. Another roadblock is that we are still stuck
    on 0.42.5
    which makes patch integration so much more difficult into the
    0.43
    branch.

    That said, we would love to get some feedback/testers. The
    tarball is
    for *linux only* clients (a good number of optimizations have
    not been
    tested on other platforms and there are already known issues,
    particularly in respect to pd.tk file).

    Some of the notable improvements include much faster editor
    (instead of
    redrawing we tag and move objects wherever possible while
    still allowing
    for legacy movement of objects not conforming to the pd
    vanilla
    gobj_displace format), bunch of usability improvements (e.g.
    custom
    color picker with color storing and hex editing), per-canvas
    toggling of
    menu and background color (see Abstractions), universal
    shortcuts,
    different scrolling algorithm. Likewise, the UI is entirely
    revamped to
    better fit the "Gnome-ish" feel. Jack connectivity algorithm
    also is
    automated and compensates for changes in srate, etc.

    At any rate, there are bunch of other little/big fixes I
    honestly cannot
    recall. These improvements are a product of a year of use
    within the
    context of a 15-member laptop orchestra taking into an account
    feedback
    from students/participants, including also my latest
    hac-a-thon this
    past week that involved overhauling redraw to improve editor
    speed. So,
    if any of you would be so kind as to give it a stab and
    provide any
    feedback, that would be most appreciated.

    You can get the latest snapshot from
    http://l2ork.music.vt.edu/main/?page_id=56

    The source tarball also includes prebuilt binaries, so
    assuming you have
    an intel machine with Ubuntu 9.10, it should "just run." (cd
    pd/bin/
    followed by ./pd). Otherwise, you may have to rebuild it
    (standard
    pd-extended 0.42.x procedure).

    Your feedback, particularly bug-reports are most appreciated.

    Best wishes,

    Ico


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

Hi Ico

cd pd/src

make distclean aclocal autoconf ./configure (with flags you wish to use, typically --prefix=/usr --enable-jack --enable-alsa) make cp pd.tk ../bin (old stale one crept into the tarball inside the bin directory--I will fix this shortly and reupload the tarball)

at that point you can either: cd ../bin ./pd

or (if you feel like this version is worthy being installed system-wide) make install pd

I have gotten further with compiling but I do get the following error at make install:

t_main.c

t_main.c:18:16: error: tk.h: No such file or directory

t_main.c:38: error: expected ‘)’ before ‘*’ token

t_main.c: In function ‘main’:

t_main.c:59: warning: implicit declaration of function ‘Tk_Main’

t_main.c:59: error: ‘Tcl_AppInit’ undeclared (first use in this function)

t_main.c:59: error: (Each undeclared identifier is reported only once

t_main.c:59: error: for each function it appears in.)

t_main.c: At top level:

t_main.c:86: warning: function declaration isn’t a prototype

t_main.c: In function ‘Tcl_AppInit’:

t_main.c:86: error: expected declaration specifiers before ‘Tcl_Interp’

t_main.c:85: warning: type of ‘interp’ defaults to ‘int’

t_main.c:88: error: ‘Tk_Window’ undeclared (first use in this function)

t_main.c:88: error: expected ‘;’ before ‘mainwindow’

t_main.c:90: warning: implicit declaration of function ‘Tcl_Init’

t_main.c:90: error: ‘TCL_ERROR’ undeclared (first use in this function)

t_main.c:93: warning: implicit declaration of function ‘Tk_Init’

t_main.c:99: warning: implicit declaration of function ‘pdgui_startup’

t_main.c:112: error: ‘TCL_OK’ undeclared (first use in this function)

make: *** [t_main.o] Error 1

Thanks for any tips-almost got it going

On Tue, Nov 23, 2010 at 8:37 AM, João Pais jmmmpais@googlemail.com wrote:

Hi,

this sounds great. I might have a chance to try it next week (back to dsl), if I have a break. But some questions in advance:

• is there a "release program"? are the testers to make sure the

implementations are working well, or do you still take requests?

• what is going to happen to all this work, hopefully be integrated in

pd-van/ext?

• will someone put the code to work in all systems? (especially windows)

• will you/your team continue to make improvements here (there are really

lots of things that can be done), or was this a one-off project?

• is there a feature list, to know how to test the novelties?

• did you look at vvvv? in an informal presentation here one of their

developers said that he was inspired by pd, but added lots of details that make the user experience much faster and easier, sometimes just by implementing small details (let the mouse over an outlet to see the values, etc.).

Best,

João

---

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

On Nov 23, 2010, at 9:29 AM, Ivica Ico Bukvic wrote:

...

• is there a "release program"? are the testers to make sure the

implementations are working well, or do you still take requests?

Not only requests but also active contributions are very much
welcome. Ideally, patches provided would be both pd vanilla and our
pd-compatible, so that theoretically everyone can benefit.

...

• what is going to happen to all this work, hopefully be integrated

in pd-van/ext?

I've tried sending over dozen patches upstream over the past year
(and there are at least another half-dozen I need to submit). While
some have made it into vanilla Pd, many of them haven't. I think
partially because most of the core devs are plugging away at 0.43
which for me is a no go as of right now as I need something that is
as production-ready and bug-free as possible. Other reasons include
possibly the fact that some of the patches may be seen as
controversial in terms of how they tackle issues. E.g. scrolling
algorithm fundamentally changes how canvas spatial context is being
calculated and as such it may take some time to adjust to.

Tldr; While I hope all patches I've submitted do make it upstream, I
have no way of knowing. 0.43 will get there and possibly soon but I
don't feel comfortable running it yet.

We definitely welcome improvements, the problem is that these patches
are for 0.42, and the Tcl code in 0.43 has changed immensely.
Hopefully you can port them to 0.43, that would be a necessary step
for me to include them.

...

• will someone put the code to work in all systems? (especially

windows)

That someone would have to be someone else than me as I am swamped
as it is and quite frankly other OSs are not (and will likely never
be) a priority in L2Ork. That said, I will gladly merge whatever
improvements I can get in this respect. We've already put a decent
amount of work inside pd.tk to allow better separation of Linux from
other Oss in terms of customizations but it has not been consistent
throughout, so it is a simple matter of tracking those
inconsistencies down and adjusting accordingly.

...

• will you/your team continue to make improvements here (there are

really lots of things that can be done), or was this a one-off project?

As best as we can. At this point it is mainly me and occasionally I
get some student help.

...

• is there a feature list, to know how to test the novelties?

I should've done a laundry list of these as I went but somewhere
along the road I lost track so honestly I don't know just how many
fixes are there. That said, I am quite sure there easily dozens upon
dozens of them in this release alone.

...

• did you look at vvvv? in an informal presentation here one of their

developers said that he was inspired by pd, but added lots of
details that make the user experience much faster and easier, sometimes just by implementing small details (let the mouse over an outlet to see the values, etc.).

I saw it briefly and I agree there are a lot of options that could
be added. I think the important question which ones should be given
greatest priority.

e.g. I am right now thinking it would be nice to have resizable cnv
just by clicking on its bottom-right corner. Ditto for other visual
iemgui objects. Another thing I would really like to see soon is
ability to box-select patch cords. Then perhaps an undo doubly- linked list would be nice as well (although not sure how hard this
would be).

Perhaps you'd be interested in my unreleased tkwidgets library, its in
SVN. Basically, I am working on creating a framework to make it much
easier to make GUI objects. Part of that framework includes things
like resizing things with the mouse. I have that much working but its
buggy still. Once that gets ironed out, I plan on making Pd versions
of all the core Tk widgets, including the Tk canvas. In tkwdigets
there is already a [text] object that works quite nicely, save a few
bugs.

.hc

HTH

Best wishes,

Ico

...

Best,

João

---

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

As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin

...

Perhaps you'd be interested in my unreleased tkwidgets library, its
in SVN. Basically, I am working on creating a framework to make it
much easier to make GUI objects. Part of that framework includes
things like resizing things with the mouse. I have that much
working but its buggy still. Once that gets ironed out, I plan on
making Pd versions of all the core Tk widgets, including the Tk
canvas. In tkwdigets there is already a [text] object that works
quite nicely, save a few bugs.

I forgot to add, my experience with the iemgui code has told me that
they would be very difficult to improve, hence the tkwidgets lib.

Unfortunately, if it is not finished/stable, I am not interested in it as having to deal with Pd bugs in and of themselves is demanding enough on my time. On a flip side Scope~ external already has similar functionality which seems to me quite complete so it may be simply a matter of implementing that one (obviously it would only apply to iemgui objects as vanilla objects have no way of knowing their own size).

That said, I did spend most of today implementing Sarlo's feature as well as fixing buggy Tcl/Tk behavior (namely inability to show check marks in the edit menu which is so disheartening it is not even funny--I really think Pd needs to wean itself away from the Tcl/Tk abomination even if that means losing a good chunk of its externals before it can thrive).

NB: I left out "drop shadows" part as it seems quite redundant. I also changed how the rest of the code behaves/looks to make it visually cleaner/more consistent.

Apart from that latest update also includes edit menu highlighting (as 0.43 does to bypass Tcl/Tk buggy junk), improved shortucts for some of the calls, bugfix in the window list menu which for some reason omits parent window listing, and other minor cosmetic fixes (e.g. highlighting color changed to orange as I feel it is much easier on my eyes).

If interested, check out the latest snapshot at the usual place:

http://l2ork.music.vt.edu/main/?page_id=56

Cheers!

Notice that both [cyclone/Scope~] and [flatspace/entry] have a bug: a sudden increase in height/width by about 5-10 pixels when you initially drag to resize. This makes it difficult if not impossible to make minor size changes (especially since there is no Properties dialogue).

Good to know. I will look into this when I get there. Currently working on accelerating iemgui objects as well as exposing them to sarlo's highlighting magic.

Wouldn't it be easier just to toggle the text for that menu option between "Edit mode" and "Run mode"? (That's what they're called in the manual.)

Sure. There are other options, too, like the one 0.43 and now l2ork version of 0.42 uses by changing option's background which works visually relatively well (albeit at the expense of consistency). This is however not the issue. The issue is finding out that after an hour of debugging the problem is not in you or your code but the toolkit you are using and in 2010 for a toolkit that has been around for more than a decade that is plainly sad.

How would you go about doing that?

A: Ugly path: Isolate pd<->gui hooks and port the entire thing to Qt.

B: Better (albeit more time-consuming) path: clean-up code first so that all objects can utilize the same gobj_<whatever> calls and then do the A: (which at that point won't be nearly as ugly or difficult to maintain).

FWIW, my first ever GUI app was RTMix I did back in 2001 and it was (and remains) the ugliest hack ever (basically I tried to learn how to program doing that app). Yet, the fact remains even in 2001 qt was way better than what Tk is today. Another advantage is avoiding socket bottlenecks as the entire thing could be done simply in C. License-wise it should be fine and cross-platform-wise miles ahead of Tcl/Tk. Heck, you could even throw in Qt for mobile devices for good measure since that is apparently hot item these days.

That said, I need some more time working with Pd code before I can undertake this. Perhaps more importantly, I just need a generous, uninterrupted chunk of time to do this.

Best wishes,

Ico

Hi Just to clarify the message Program received signal SIGSEGV, Segmentation fault. 0x00000011 in ?? ()

is printed on the terminal when ctrl-1 is used

Thanks again On Wed, Nov 24, 2010 at 10:11 AM, ALAN BROOKER alan.brooker2010@gmail.comwrote:

Hi Ico

Ive got it working and have loaded some libraries, Gem, Gridflow, Zexy, pdp

• however PD crashes out when I ctrl-1 to put an object on the canvas.

I've done a backtrace (thanks Mathieu for the tip previously) with the following results:

Starting program: /usr/local/bin/pd -oss -channels 2 my-bug-test.pd [Thread debugging using libthread_db enabled] <init> : Avifile RELEASE-0.7.48-100119-21:44-../src/configure <init> : Available CPU flags: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc nonstop_tsc extd_api <init> : 800.00 MHz AMD Phenom(tm) II X2 555 Processor detected [New Thread 0xb47e1b70 (LWP 4084)]

Program received signal SIGSEGV, Segmentation fault. 0x00000011 in ?? () (gdb) where #0 0x00000011 in ?? () #1 0x080a94d5 in gobj_displace_withtag (x=0x8206cb8, dx=<value optimised out>, dy=0) at g_editor.c:68 #2 canvas_displaceselection (x=0x8206cb8, dx=<value optimised out>, dy=0) at g_editor.c:1900 #3 0x080a98a5 in canvas_motion (x=0x8206cb8, xpos=232, ypos=76, fmod=2) at g_editor.c:2089 #4 0x080ca4f6 in pd_typedmess (x=0x8206cb8, s=0x8135eb8, argc=3, argv=0xbffff08c) at m_class.c:792 #5 0x080ca0dc in pd_typedmess (x=0x814ac60, s=0x8135eb8, argc=3, argv=0xbffff08c) at m_class.c:813 #6 0x080cfbaa in binbuf_eval (x=0x8149688, target=<value optimised out>, argc=0, argv=0x0) at m_binbuf.c:726 #7 0x080dde5f in socketreceiver_read (x=0x81496a8, fd=6) at s_inter.c:560 #8 0x080dd81a in sys_domicrosleep (microsec=<value optimised out>, pollem=<value optimised out>) at s_inter.c:198 #9 0x080de502 in sys_pollgui () at s_inter.c:862 #10 0x080d9321 in m_pollingscheduler () at m_sched.c:490 #11 m_mainloop () at m_sched.c:560 #12 0x080dc8a9 in sys_main (argc=5, argv=0xbffff4e4) at s_main.c:310 #13 0x080e556b in main (argc=5, argv=0xbffff4e4) at s_entry.c:32 (gdb) quit A debugging session is active.

Inferior 1 [process 4078] will be killed.

Quit anyway? (y or n) y socket receive error: Connection reset by peer (104)

Thanks for your help with this! It's a great package to work from Cheers

On Wed, Nov 24, 2010 at 5:29 AM, Ivica Ico Bukvic ico@vt.edu wrote:

...

...

Notice that both [cyclone/Scope~] and [flatspace/entry] have a bug: a sudden increase in height/width by about 5-10 pixels when you initially drag to resize. This makes it difficult if not impossible to make minor size changes (especially since there is no Properties dialogue).

Good to know. I will look into this when I get there. Currently working on accelerating iemgui objects as well as exposing them to sarlo's highlighting magic.

...

Wouldn't it be easier just to toggle the text for that menu option between "Edit mode" and "Run mode"? (That's what they're called in the manual.)

Sure. There are other options, too, like the one 0.43 and now l2ork version of 0.42 uses by changing option's background which works visually relatively well (albeit at the expense of consistency). This is however not the issue. The issue is finding out that after an hour of debugging the problem is not in you or your code but the toolkit you are using and in 2010 for a toolkit that has been around for more than a decade that is plainly sad.

...

How would you go about doing that?

A: Ugly path: Isolate pd<->gui hooks and port the entire thing to Qt.

B: Better (albeit more time-consuming) path: clean-up code first so that all objects can utilize the same gobj_<whatever> calls and then do the A: (which at that point won't be nearly as ugly or difficult to maintain).

FWIW, my first ever GUI app was RTMix I did back in 2001 and it was (and remains) the ugliest hack ever (basically I tried to learn how to program doing that app). Yet, the fact remains even in 2001 qt was way better than what Tk is today. Another advantage is avoiding socket bottlenecks as the entire thing could be done simply in C. License-wise it should be fine and cross-platform-wise miles ahead of Tcl/Tk. Heck, you could even throw in Qt for mobile devices for good measure since that is apparently hot item these days.

That said, I need some more time working with Pd code before I can undertake this. Perhaps more importantly, I just need a generous, uninterrupted chunk of time to do this.

Best wishes,

Ico

---

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

On Wed, Nov 24, 2010 at 6:40 PM, Ivica Ico Bukvic ico@vt.edu wrote:

OK, latest snapshot 20101124 has been just made available in the usual place with additional improvements including:

*all vanilla and iemgui objects are now "accelerated" in terms of their redrawing and moving, resulting in a dramatic improvement in UI responsiveness (for the devs, the new model uses tagging of widgets and move command, rather than apparently a much more cpu expensive coords call)

*sarlo's magic highlighter now works on all iem objects as well as gop objects

*more cosmetic bug fixes

http://l2ork.music.vt.edu/main/?page_id=56

As always, feedback is most appreciated!

Best wishes,

Ico

<personal thoughts, never mind> First i wish to say i had my doubts but now i'm happy to see an iteration of pd-extended in the wild. One may say there is some waste of time with a fork like this and of course there is, but it also proves pd-extended to be 'adult' in a way and adults may have children, and children may seem to reinvent the wheel sometimes but that's all right and that's the way they can find their new, hopefully better ways. And meanwhile, hopefully, many thing will go upstream and it will be a big happy family :o) I'm particularly interested in better GUIs operating a well separated core, and happy to see Hans & Miller & al are advancing in this direction! </personal thoughts, never mind>

I'm on AMD64 and has run into this with 'make':

cd ../obj; cc -Wl,-export-dynamic -lasound -lrt -ljack -o ../bin/pd d_ctl.o d_array.o d_delay.o d_filter.o d_math.o d_osc.o d_soundfile.o g_canvas.o g_graph.o g_text.o g_rtext.o g_array.o g_template.o g_io.o g_scalar.o g_traversal.o g_guiconnect.o g_readwrite.o g_editor.o g_all_guis.o g_bang.o g_hdial.o g_hslider.o g_mycanvas.o g_numbox.o g_toggle.o g_vdial.o g_vslider.o g_vumeter.o g_magicglass.o m_pd.o m_class.o m_obj.o m_atom.o m_memory.o m_binbuf.o m_conf.o m_glob.o m_sched.o s_main.o s_inter.o s_file.o s_print.o s_loader.o s_path.o s_entry.o s_audio.o s_midi.o d_ugen.o d_arithmetic.o d_dac.o d_misc.o d_fft.o d_global.o d_resample.o x_arithmetic.o x_connective.o x_interface.o x_midi.o x_misc.o x_time.o x_acoustics.o x_net.o x_qlist.o x_gui.o x_list.o import.o s_midi_oss.o s_audio_oss.o s_audio_alsa.o s_audio_alsamm.o s_midi_alsa.o s_audio_jack.o d_fft_mayer.o d_fftroutine.o -ldl -lm -lpthread -lasound collect2: ld terminated with signal 11 [Segmentation fault] /usr/bin/ld: i386 architecture of input file d_ctl.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input filed_array.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file d_delay.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input filed_filter.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file d_math.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input filed_osc.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file g_canvas.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input fileg_graph.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file g_text.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input fileg_rtext.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file g_array.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input fileg_template.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file g_io.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input fileg_scalar.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file g_traversal.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input fileg_guiconnect.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file g_readwrite.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input fileg_editor.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file g_vdial.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input fileg_magicglass.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file m_pd.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input filem_obj.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file m_atom.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input filem_memory.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file m_conf.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input filem_glob.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file s_main.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input files_print.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file s_loader.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input files_path.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file s_entry.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input filed_ugen.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file d_arithmetic.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input filed_dac.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file d_misc.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input filed_fft.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file d_global.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input filed_resample.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file x_connective.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input filex_interface.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file x_midi.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input filex_time.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file x_acoustics.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input filex_net.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file import.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input files_audio_oss.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file s_audio_alsa.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input files_audio_alsamm.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file s_audio_jack.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input filed_fft_mayer.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `d_fftroutine.o' is incompatible with i386:x86-64 output make: *** [../bin/pd] Error 1

Andras

On Wed, 2010-11-24 at 17:21 -0500, Hans-Christoph Steiner wrote:

Just started it up to try the up/down ordering feature, I'm on Ubuntu Lucid i386. I found a bug. With the attached patch, do this:

1. delete the [adsf(
2. highlight the upper left corner of the [cnv] canvas
3. hit Ctrl-down

For me, the [asdf( message comes back. Also, I can't get the [cnv] to change ordering, only the [hsl].

I'll explore some more.

Just tested this and cannot reproduce it. This has been definitely fixed in the yesterday's (or perhaps today's) snapshot so please try that one instead as there was a bug Jonathan reported which prompted me to rewrite to front/back part.

Best wishes,

Ico

On Wed, 2010-11-24 at 17:26 -0500, Hans-Christoph Steiner wrote:

The new connect mouse cursor is quite nice, and the inlet highlighting. There is a minor bug with the inlet highlighting, for the blue/gray solid audio inlets, after they get highlighted they inherit the black box of the message inlets.

Back to testing!

I just fixed this. It will be released in the next tarball.

On Wed, 2010-11-24 at 17:31 -0500, Hans-Christoph Steiner wrote:

Wow, the magicglass feature is really nice. I just have one comment about it: it would be nice to have it flash whenever a new message came in. For example, if you stick it below a metro, it'll just say bang, so you don't know if its a stream of bangs, or just one bang. Having the text change color or the background each time a new message came in would show that info. In pddp/print I made it background flash yellow whenever a bang came in.

(and a random aside, perhaps you'd be interested in getting Pd to use the GTK open panel? I've always hated the Tcl/Tk one).

.hc

And here's a little bug in the magicglass, in the attached patch, if you look at the cord beneath [list x.wav 44100(, it shows "x.wav 44100" which is different than "list x.wav 44100".

.hc

(and a random aside, perhaps you'd be interested in getting Pd to use the GTK open panel? I've always hated the Tcl/Tk one).

How would one go about doing this?

On Wed, 2010-11-24 at 23:48 -0500, Hans-Christoph Steiner wrote:

On Nov 24, 2010, at 10:59 PM, Ivica Ico Bukvic wrote:

...

...

(and a random aside, perhaps you'd be interested in getting Pd to use the GTK open panel? I've always hated the Tcl/Tk one).

How would one go about doing this?

I believe that gnocl is the thing that you are looking for:

http://wiki.tcl.tk/5151

Way cool! How come no one else tried this before?

Ico

Hans-Christoph Steiner wrote:

On Nov 24, 2010, at 10:59 PM, Ivica Ico Bukvic wrote:

...

...

(and a random aside, perhaps you'd be interested in getting Pd to use the GTK open panel? I've always hated the Tcl/Tk one).

How would one go about doing this?

I believe that gnocl is the thing that you are looking for:

http://wiki.tcl.tk/5151

Actually a really 'quick and dirty' solution would be to call zenity 1 from within the tk.. Which IMHO is better than the Tk file opener.. Attached a version of pd.tk (0.42.5-extended-rc5 linux) which will try touse zenity for open, falling back to Tk if zeniy is not found (sorry my tcl is really really rusty :-)

Lorenzo.

.hc

---

"Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you." - Richard M. Stallman

---

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

[this was intended for the list by I sent it to Hans only by mistake - resending]

-------- Original Message -------- Subject: zenity plugin for Pd 0.43 WAS: magicglass WAS: call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) From: Hans-Christoph Steiner hans@at.or.at To: Lorenzo Sutton lsutton@libero.it CC: pd-list@iem.at Date: 11/28/2010 02:00 AM

On Nov 25, 2010, at 6:27 AM, Lorenzo Sutton wrote:

...

Hans-Christoph Steiner wrote:

...

On Nov 24, 2010, at 10:59 PM, Ivica Ico Bukvic wrote:

...

...

(and a random aside, perhaps you'd be interested in getting Pd to use the GTK open panel? I've always hated the Tcl/Tk one).

How would one go about doing this?

I believe that gnocl is the thing that you are looking for:

http://wiki.tcl.tk/5151

Actually a really 'quick and dirty' solution would be to call zenity 1 from within the tk.. Which IMHO is better than the Tk file opener.. Attached a version of pd.tk (0.42.5-extended-rc5 linux) which will try touse zenity for open, falling back to Tk if zeniy is not found (sorry my tcl is really really rusty :-)

Lorenzo.

That would make a great GUI plugin for Pd 0.43. Basically the plugin would just override pdtk_openpanel and pdtk_savepanel (now in pd/tcl/wheredoesthisgo.tcl). Just 'rename' the existing ones in your plugin, then create your own procs with the same names.

.hc

The GUI plugin thing in 0.43 is pretty new to me.. Anything I can read to learn about it?

This apporach (that's why 'quick and dirty') does have various limitations that I think couldn't be solved:

• No way to have 'filetype' filters (I haven't seen a way to have ore

than one with zenity)

• Doesn't remember last opened directory (but maybe taht could be

handled by the tk script)

• Not exactly the 'standard' gnome open dialogue.

Of course one could create two small independent gtk+ (or whatever gui) apps (executables) that let you select file in a "natve" look and feel spit a string out a string like zenity which is easily ingested y tk. I'm not sure how this could be made cross platform though.

Lorenzo.

---

Using ReBirth is like trying to play an 808 with a long stick.
-David Zicarelli

Hey Andras, this is great! My only request is: can we call them "GUI
plugins"? "startup plugins" sounds too vague for me. Also, here's a
bit more documentation:

http://puredata.info/docs/PdGuiPluginsAPI

Now I'm thinking we should start a "guiplugins" wiki folder section in
the doc wiki, so like:

http://puredata.info/docs/guiplugins (this would be your page, also
be called FrontPage) http://puredata.info/docs/guiplugins/GuiPluginsAPI http://puredata.info/docs/guiplugins/ExamplePlugins

How does that sound?

.hc

On Nov 29, 2010, at 3:29 PM, András Murányi wrote:

I have started a Wiki page on this: http://puredata.info/docs/developer/StartupPlugins I'll expand it later today.

Andras

On Mon, Nov 29, 2010 at 3:31 PM, Lorenzo Sutton lsutton@libero.it
wrote: [this was intended for the list by I sent it to Hans only by mistake

• resending]

-------- Original Message -------- Subject: zenity plugin for Pd 0.43 WAS: magicglass WAS: call for
testers for L2Ork iteration of pd-extended (based on 0.42.x branch) From: Hans-Christoph Steiner hans@at.or.at To: Lorenzo Sutton lsutton@libero.it CC: pd-list@iem.at Date: 11/28/2010 02:00 AM

On Nov 25, 2010, at 6:27 AM, Lorenzo Sutton wrote:

Hans-Christoph Steiner wrote:

On Nov 24, 2010, at 10:59 PM, Ivica Ico Bukvic wrote:

(and a random aside, perhaps you'd be interested in getting Pd to use the GTK open panel? I've always hated the Tcl/Tk one).

How would one go about doing this?

I believe that gnocl is the thing that you are looking for:

http://wiki.tcl.tk/5151 Actually a really 'quick and dirty' solution would be to call zenity
1 from within the tk.. Which IMHO is better than the Tk file
opener.. Attached a version of pd.tk (0.42.5-extended-rc5 linux)
which will try touse zenity for open, falling back to Tk if zeniy is
not found (sorry my tcl is really really rusty :-)

Lorenzo.

That would make a great GUI plugin for Pd 0.43. Basically the
plugin would just override pdtk_openpanel and pdtk_savepanel (now in
pd/tcl/wheredoesthisgo.tcl). Just 'rename' the existing ones in
your plugin, then create your own procs with the same names.

.hc The GUI plugin thing in 0.43 is pretty new to me.. Anything I can
read to learn about it?

This apporach (that's why 'quick and dirty') does have various
limitations that I think couldn't be solved:

• No way to have 'filetype' filters (I haven't seen a way to have

ore than one with zenity)

• Doesn't remember last opened directory (but maybe taht could be

handled by the tk script)

• Not exactly the 'standard' gnome open dialogue.

Of course one could create two small independent gtk+ (or whatever
gui) apps (executables) that let you select file in a "natve" look
and feel spit a string out a string like zenity which is easily
ingested y tk. I'm not sure how this could be made cross platform
though.

Lorenzo.

---

Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli

---

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

I spent 33 years and four months in active military service and during
that period I spent most of my time as a high class muscle man for Big
Business, for Wall Street and the bankers. - General Smedley Butler

On Nov 29, 2010, at 4:43 PM, András Murányi wrote:

2010/11/29 Hans-Christoph Steiner hans@at.or.at

Hey Andras, this is great! My only request is: can we call them
"GUI plugins"? "startup plugins" sounds too vague for me. Also,
here's a bit more documentation:

http://puredata.info/docs/PdGuiPluginsAPI

Now I'm thinking we should start a "guiplugins" wiki folder section
in the doc wiki, so like:

http://puredata.info/docs/guiplugins (this would be your page, also
be called FrontPage) http://puredata.info/docs/guiplugins/GuiPluginsAPI http://puredata.info/docs/guiplugins/ExamplePlugins

How does that sound?

.hc

Sounds great. Please go ahead and rename & move 'my' page, then i'll
go on.

Andras

Ok here goes:

http://puredata.info/docs/guiplugins/ http://puredata.info/docs/guiplugins/SimpleExamples http://puredata.info/docs/guiplugins/GuiPluginsAPI

Some possible fodder for more stuff for the Gui Plugins wiki: http://puredata.info/dev/PdGuiRewriteTheming

So the current FrontPage and the GuiPluginsAPI pages have some
overlap, and should be combined. Andras, if you can take that on,
please do. You're page looks quite good so far.

.hc

                         kill your television

On Nov 30, 2010, at 4:16 PM, András Murányi wrote:

2010/11/30 Hans-Christoph Steiner hans@at.or.at

On Nov 29, 2010, at 4:43 PM, András Murányi wrote:

...

2010/11/29 Hans-Christoph Steiner hans@at.or.at

Hey Andras, this is great! My only request is: can we call them
"GUI plugins"? "startup plugins" sounds too vague for me. Also,
here's a bit more documentation:

http://puredata.info/docs/PdGuiPluginsAPI

Now I'm thinking we should start a "guiplugins" wiki folder section
in the doc wiki, so like:

http://puredata.info/docs/guiplugins (this would be your page,
also be called FrontPage) http://puredata.info/docs/guiplugins/GuiPluginsAPI http://puredata.info/docs/guiplugins/ExamplePlugins

How does that sound?

.hc

Sounds great. Please go ahead and rename & move 'my' page, then
i'll go on.

Andras

Ok here goes:

http://puredata.info/docs/guiplugins/ http://puredata.info/docs/guiplugins/SimpleExamples http://puredata.info/docs/guiplugins/GuiPluginsAPI

Some possible fodder for more stuff for the Gui Plugins wiki: http://puredata.info/dev/PdGuiRewriteTheming

So the current FrontPage and the GuiPluginsAPI pages have some
overlap, and should be combined. Andras, if you can take that on,
please do. You're page looks quite good so far.

.hc

OK, i have my request concerning combining... or rather a question: it is not a real API that we're having and may be misleading to call
it so, still API is a word that is good lead for somewhone looking
for anything that plays the role of an API... what do you think? is
there a better word to use, or we just call it API and then explain
it's nor really? (or do you consider it an API?)

I'm not stuck on the term API, but the stuff that I outlined there is
stuff that I added to the new GUI code specifically to support
plugins, rather than internal needs. Of course, being Tcl, a plugin
can override really anything, so all of the GUI code can't really be
called the API, tho it could be changed by a plugin.

Does that make sense?

.hc

                                           http://at.or.at/hans/

Hans-Christoph Steiner wrote:

On Nov 25, 2010, at 6:27 AM, Lorenzo Sutton wrote:

...

Hans-Christoph Steiner wrote:

...

On Nov 24, 2010, at 10:59 PM, Ivica Ico Bukvic wrote:

...

...

(and a random aside, perhaps you'd be interested in getting Pd to use the GTK open panel? I've always hated the Tcl/Tk one).

How would one go about doing this?

I believe that gnocl is the thing that you are looking for:

http://wiki.tcl.tk/5151

Actually a really 'quick and dirty' solution would be to call zenity 1 from within the tk.. Which IMHO is better than the Tk file opener.. Attached a version of pd.tk (0.42.5-extended-rc5 linux) which will try touse zenity for open, falling back to Tk if zeniy is not found (sorry my tcl is really really rusty :-)

Lorenzo.

That would make a great GUI plugin for Pd 0.43. Basically the plugin would just override pdtk_openpanel and pdtk_savepanel (now in pd/tcl/wheredoesthisgo.tcl). Just 'rename' the existing ones in your plugin, then create your own procs with the same names.

Actually I was replacing the menu items. I see that in 0.43 these are in pd_menucommands.tcl but from the examples I have no clue how to replace that... Hints would be appreciated :)

Lorenzo

.hc

---

Using ReBirth is like trying to play an 808 with a long stick.
-David Zicarelli

On Thu, 9 Dec 2010, Hans-Christoph Steiner wrote:

rename pdtk_openpanel pdtk_openpanel_original proc pdtk_openpanel {target localdir} { # my own custom open panel code }

The «rename» command is only useful when you do need the original proc.

Here, you don't.

| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC

On Nov 24, 2010, at 12:29 AM, Ivica Ico Bukvic wrote:

...

Notice that both [cyclone/Scope~] and [flatspace/entry] have a bug: a sudden increase in height/width by about 5-10 pixels when you initially drag to resize. This makes it difficult if not impossible to make minor size changes (especially since there is no Properties dialogue).

Good to know. I will look into this when I get there. Currently
working on accelerating iemgui objects as well as exposing them to
sarlo's highlighting magic.

I just realize that there are two iemgui libs in a sense: there are
the iemgui objects that have been included in Pd-vanilla for 10 years,
those are the ones I was referring to. Then there is the new iemgui
library in pure-data SVN, I know little about that one. Which one are
you referring to?

...

Wouldn't it be easier just to toggle the text for that menu option between "Edit mode" and "Run mode"? (That's what they're called in the manual.)

Sure. There are other options, too, like the one 0.43 and now l2ork
version of 0.42 uses by changing option's background which works
visually relatively well (albeit at the expense of consistency).
This is however not the issue. The issue is finding out that after
an hour of debugging the problem is not in you or your code but the
toolkit you are using and in 2010 for a toolkit that has been around
for more than a decade that is plainly sad.

FYI, 0.43 fixes this issue by changing the 'editmode' message so that
1 means editmode is on, and 0 means editmode is off. Before that, the
'editmode' message toggled edit mode. That's what made it so
difficult to make the menu item checkbox work. These are the kinds of
things that I have spent many many hours working to fix, so it makes
me sad to see you reinventing the wheel.

Also, since everything is always running in Pd, I'd much prefer to see
it called "Edit Mode" and "Play Mode".

...

How would you go about doing that?

A: Ugly path: Isolate pd<->gui hooks and port the entire thing to Qt.

B: Better (albeit more time-consuming) path: clean-up code first so
that all objects can utilize the same gobj_<whatever> calls and then
do the A: (which at that point won't be nearly as ugly or difficult
to maintain).

FWIW, my first ever GUI app was RTMix I did back in 2001 and it was
(and remains) the ugliest hack ever (basically I tried to learn how
to program doing that app). Yet, the fact remains even in 2001 qt
was way better than what Tk is today. Another advantage is avoiding
socket bottlenecks as the entire thing could be done simply in C.
License-wise it should be fine and cross-platform-wise miles ahead
of Tcl/Tk. Heck, you could even throw in Qt for mobile devices for
good measure since that is apparently hot item these days.

That said, I need some more time working with Pd code before I can
undertake this. Perhaps more importantly, I just need a generous,
uninterrupted chunk of time to do this.

Peter Brinkmann, Peter Kirn, Miller and I all had a meeting recently
to discuss the idea of making 'pd' a separate entity. My part is
making pd talk to pd-gui using pd messages, then it should be pretty
straightforward to making new GUIs in lots of different toolkits.

.hc

"Free software means you control what your computer does. Non-free
software means someone else controls that, and to some extent controls
you." - Richard M. Stallman

On Wed, 2010-11-24 at 14:06 -0500, Ivica Ico Bukvic wrote:

...

I just realize that there are two iemgui libs in a sense: there are the iemgui objects that have been included in Pd-vanilla for 10

years,

...

those are the ones I was referring to. Then there is the new iemgui library in pure-data SVN, I know little about that one. Which one

are

...

you referring to?

I am referring to the one that has been a part of pd for a long time. This is the one I just updated in the latest release so that moving of its widgets in edit mode is now a part of a single move-by-tag call. I am actually quite pleased how it works now.

That sounds like something that should have been done a while ago. My big worry here is regression bugs. So we'll need to come up with a bunch of tests so we can make sure the faster code doesn't introduce bugs. I think the only place we are going to see big benefits for move code is in redrawing arrays, the drawing is pretty simple in most other GUI objects.

...

FYI, 0.43 fixes this issue by changing the 'editmode' message so

that

...

1 means editmode is on, and 0 means editmode is off. Before that,

the

...

'editmode' message toggled edit mode. That's what made it so difficult to make the menu item checkbox work. These are the kinds

of

...

things that I have spent many many hours working to fix, so it makes me sad to see you reinventing the wheel.

I am not reinventing wheel in this case but simply backporting your solution (unless you are referring to me wasting hours as you did on the Tcl widget bug as the actual reinventing of the wheel). Either way, the checkmark next to the checkbutton widget is simply buggy and does not show up when it should (e.g. when invoking the widget). This is the case even with 0.43 gui rewrite. The only way one can "see" that the option has been activated on 0.43 (and now on l2ork iteration of 0.42) is by the fact "edit mode" option in the menu has changed its background color to green (which actually does not look all that bad, even though it is inconsistent with general menu UI guidelines Tcl/Tk is supposedly trying so hard to enforce).

Yeah, I hear you. I think the background color thing works well for GNOME, not sure about anything else tho. Changing the text between "Edit Mode" and "Play Mode" is a viable option for all platforms IMHO.

...

Peter Brinkmann, Peter Kirn, Miller and I all had a meeting recently to discuss the idea of making 'pd' a separate entity. My part is making pd talk to pd-gui using pd messages, then it should be pretty straightforward to making new GUIs in lots of different toolkits.

As long as those messages are not something that needs to be sent via socket but can be also prototyped into direct function calls within C. Otherwise, the solution simply perpetuates the existing problem of socket and string parser saturation, resulting in very slow performance. Notice that even with l2ork iteration of pd-extended where everything "vanilla" now uses move-by-tag approach (in other words one call moves all selected widgets except for GOPs which are quite messy thus resulting in one call vs. potentially hundreds if not thousands) and which ostensibly approaches ideal performance via socket, it still gets relatively easily bogged down due to inherent overhead.

I think there are advantages to having the GUI be a separate process, and it would be worth exploring other ways of havning pd and pd-gui talk. Shared memory is one idea. Plus for things like arrays, the data could be sent as binary thereby skipping the string parsing aspect.

.hc

On Nov 24, 2010, at 7:46 PM, Jonathan Wilkes wrote:

--- On Wed, 11/24/10, Hans-Christoph Steiner hans@at.or.at wrote:

...

From: Hans-Christoph Steiner hans@at.or.at Subject: RE: [PD] call for testers for L2Ork iteration of pd- extended (based on 0.42.x branch) To: "Ivica Ico Bukvic" ico@vt.edu Cc: "'Jonathan Wilkes'" jancsika@yahoo.com, pd-list@iem.at Date: Wednesday, November 24, 2010, 11:54 PM On Wed, 2010-11-24 at 14:06 -0500, Ivica Ico Bukvic wrote:

...

...

I just realize that there are two iemgui libs in

a sense: there are

...

...

the iemgui objects that have been included in

Pd-vanilla for 10

...

years,

...

those are the ones I was referring to. Then

there is the new iemgui

...

...

library in pure-data SVN, I know little about

that one. Which one

...

are

...

you referring to?

I am referring to the one that has been a part of pd

for a long time.

...

This is the one I just updated in the latest release

so that moving of

...

its widgets in edit mode is now a part of a single

move-by-tag call. I

...

am actually quite pleased how it works now.

That sounds like something that should have been done a while ago. My big worry here is regression bugs. So we'll need to come up with a bunch of tests so we can make sure the faster code doesn't introduce bugs. I think the only place we are going to see big benefits for move code is in redrawing arrays, the drawing is pretty simple in most other GUI objects.

...

...

FYI, 0.43 fixes this issue by changing the

'editmode' message so

...

that

...

1 means editmode is on, and 0 means editmode is

off. Before that,

...

the

...

'editmode' message toggled edit mode.

That's what made it so

...

...

difficult to make the menu item checkbox

work. These are the kinds

...

of

...

things that I have spent many many hours working

to fix, so it makes

...

...

me sad to see you reinventing the wheel.

I am not reinventing wheel in this case but simply

backporting your

...

solution (unless you are referring to me wasting hours

as you did on

...

the Tcl widget bug as the actual reinventing of the

wheel). Either

...

way, the checkmark next to the checkbutton widget is

simply buggy and

...

does not show up when it should (e.g. when invoking

the widget). This

...

is the case even with 0.43 gui rewrite. The only way

one can "see"

...

that the option has been activated on 0.43 (and now on

l2ork iteration

...

of 0.42) is by the fact "edit mode" option in the menu

has changed its

...

background color to green (which actually does not

look all that bad,

...

even though it is inconsistent with general menu UI

guidelines Tcl/Tk

...

is supposedly trying so hard to enforce).

Yeah, I hear you. I think the background color thing works well for GNOME, not sure about anything else tho. Changing the text between "Edit Mode" and "Play Mode" is a viable option for all platforms IMHO.

If you do this please call it "Run mode" and not "Play mode".

It's "run mode" in the manual, as well as a lot of the docs, tutorials, and internal help patches.

Right, I'm proposing changing it everywhere. "run mode" implies that
things aren't running in "edit mode", which is definitely not true.

.hc

...

...

...

Peter Brinkmann, Peter Kirn, Miller and I all had

a meeting recently

...

...

to discuss the idea of making 'pd' a separate

entity. My part is

...

...

making pd talk to pd-gui using pd messages, then

it should be pretty

...

...

straightforward to making new GUIs in lots of

different toolkits.

...

As long as those messages are not something that needs

to be sent via

...

socket but can be also prototyped into direct function

calls within C.

...

Otherwise, the solution simply perpetuates the

existing problem of

...

socket and string parser saturation, resulting in very

slow

...

performance. Notice that even with l2ork iteration of

pd-extended

...

where everything "vanilla" now uses move-by-tag

approach (in other

...

words one call moves all selected widgets except for

GOPs which are

...

quite messy thus resulting in one call vs. potentially

hundreds if not

...

thousands) and which ostensibly approaches ideal

performance via

...

socket, it still gets relatively easily bogged down

due to inherent

...

overhead.

I think there are advantages to having the GUI be a separate process, and it would be worth exploring other ways of havning pd and pd-gui talk. Shared memory is one idea. Plus for things like arrays, the data could be sent as binary thereby skipping the string parsing aspect.

.hc

If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively possess as long as he keeps
it to himself; but the moment it is divulged, it forces itself into
the possession of everyone, and the receiver cannot dispossess himself
of it. - Thomas Jefferson

OK, new snapshot 20101125 is now up with following fixes:

*removed redundant find menu *inlet and outlet highlighting reset bug (reported by Hans) *magicglass not reporting negative sig~ values *added ~ prefix to signal data magicglass monitoring *magicglass not displaying list *magicglass widget not properly resizing *added magicglass flashing indicator *fixed magicglass flicker

http://l2ork.music.vt.edu/main/?page_id=56

Next stop segfault with moonlib/mknob but this will have to wait until tomorrow as my eyelids are getting unbearably heavy...

Cheers!

ico

thanks for sharing. a couple of very minor remarks:

• • your webpage froze firefox/iceweasel on my eeepc the first time i

accessed it; i assume this is due to the animated tagcloud. is there any conceptual reason for maaking a navigation aid eat 100% on 2 cores?

I wish I had an answer for you as the cloud is pure javascript and it works just fine on my MSI wind U100 netbook (single core with hyperthreading, so I guess you could call it Intel's fake 2 cores) as well as on my Android phone (where it is somewhat slow but does not impede the rest of the webpage). I would love to hear from the others as well regarding this, because if this problem is more widespread I will look into altering/replacing it with something else.

once i managed to download it, i only played a few minutes with it, so..

• • when releasing tarballs you should get rid of the .svn folders; these

hold a copy of all files, so you could reduce the size of the unpacked bundle to about 50%

Unfortunately in my case it had no difference whatsoever as I've not used svn on this branch in some time. I believe the binaries are what is causing the tarball to be as large as it is. At any rate, I will reupload it without the .svn folder.

• • the "magnifying glass" (i think you all refer to the "Patch cord

viewer" (or "cord inspector" how i would call it) by this term), is a very nice feature. what i find weird is, that i can only switch to "cord viewing" when in edit mode; Ctrl-r in Run-mode simple doesn't do anything; i would expect to switch my patch into run mode if needed

Well, this is the way original Sarlo's code works, so I haven't given it much thought until now. Now that you brought it up, I feel like the current design makes more sense as the cord monitoring undoubtedly saps some of the CPU and as such one would probably not want to run it in "runtime/performance" mode anyhow. OTOH if you are looking to monitor what passes through the cords, this in and of itself suggests you are likely troubleshooting something and as such are looking to edit the patch anyhow, so based on these two observations alone I would say the current behavior makes sense. Then again, I may be missing something here in which case I would certainly like to hear opinions from others as well.

All that said, I like your term better.

• • the "inlet highlighting" (this looks more like a "magnifying glass" to

me) is a nice idea but it doesn't really help yet. e.g. with objects that have more inlets then available width (e.g. [pix_info]) you still have the same problem as before (though a bit bigger); i also think that the magnification amount is a bit too small, but this might be due to my very small screen size (at first i wouldn't even notice a real difference then to the original connection cursor). it would probably be a good idea to let the user change the amount of magnification)

Good idea. I'll add this to the todo (shouldn't be too hard--it really simply boils down to designing the edit menu and providing appropriate hooks). That said, what would be even better is simply adding a tooltip that reflects which inlet/outlet is selected and what it does. This was recently discussed and with the highlighting in place this would boil down to simply adding another two arrays to glist and filling them with per-object descriptors (this last part being the biggest pain as it would have to be added pd-wide). In the interim, it could simply check for null entries and ignoring those that have not been implemented.

I think I'll take a stab at this one soon.

• • why is the default selection color "orange/red"? is this a pd-extended

thing? for me this is very close to the error-indicating color "red" (e.g. when an object fails to create)

Because I find it hard to discern between blue and black (selected vs. deselected) on such thin lines that constitute most of the gui and which occurs a lot more often than the red invalid objects. That said, I will up the width on the red objects which should solve this problem.

• • something i think is only inherited from pd-extended, but whiich makes

me shout out loud, is that when i start pd-l2ork it creates a "pd-externals" folder in my home directory. even if i don't do anything apart from opening! i think this is _very_ rude.

This is indeed inherited from pd-extended and I think we need to hear from Hans on this one as I certainly wish to maintain as much pd-extended compatibility as reasonably possible. Hans?

Many thanks for your feedback!

Best wishes,

Ico

...

I think I'll take a stab at this one soon.

Before you do, you should ask Miller what exactly his comments mean in:

http://sourceforge.net/tracker/index.php?func=detail&aid=1056914&gro...

Also see:

http://sourceforge.net/tracker/index.php?func=detail&aid=2838176&gro...

Interesting. What I am missing in this patch is a prototype tooltip entries (the symbol). Are there any examples of this? Also what is not clear to me from the patch file itself is whether the tooltip is per-object or per-nlet.

Cheers!

Ico

Hi,

Ivica Ico Bukvic wrote:

[cut]

Regarding "selected" color, any suggestion if one is to avoid default blue and current orange which is apparently not that good either?

Maybe I've lost something, but any particular reason why you want to ger rid of the blue? I think most are used to it now-a-days. The orange is really uncomfortable IMHO.

Lorenzo

Best wishes,

Ico

---

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

AFAIK, with 0.43 this problem will be less serious as colors are easily changed with so-called plug-ins, i.e. tcl one-liners. BTW I like orange :o)

Andras

On Fri, Nov 26, 2010 at 10:39 AM, ALAN BROOKER alan.brooker2010@gmail.comwrote:

selecting the colour is a good option I think, but it's down to personal preference ;)

On Fri, Nov 26, 2010 at 8:24 AM, Lorenzo Sutton lsutton@libero.it wrote:

...

Hi,

Ivica Ico Bukvic wrote:

...

[cut]

Regarding "selected" color, any suggestion if one is to avoid default blue and current orange which is apparently not that good either?

Maybe I've lost something, but any particular reason why you want to ger rid of the blue? I think most are used to it now-a-days. The orange is really uncomfortable IMHO.

Lorenzo

Best wishes,

...

Ico

---

Another quick update includes following, mainly cosmetic fixes/improvements:

*made iemgui use default $select_color as defined in pd.tk while leaving legacy definition for IEM_GUI_COLOR_SELECTED color (as defined in g_all_guis.h) for other externals that may rely upon it *cleaned up bugs in mycanvas where label did not follow the object *cleaned up segfault on number2 when creating a label *modularized highlight nlet color and width and moved them to pd.tk *changed the way highlight nlet filters different objects and reverts their nlet color properly to original state (e.g. iemgui uses black as default whereas text objects use gray nlets

You can grab it from: http://l2ork.music.vt.edu/main/?page_id=56

This way anyone interested in bigger highlight or different default select colors can alter it all from the pd.tk menu (search for $select_color and below color section you'll find also highlight customization options).

Now the only remaining thing is to test various externals, which has so far gone quite well, requiring only in some cases (e.g. moonlib/mknob) a recompile of the original external with no changes to their respective sources (typically those who rely upon core .h files that may have changed slightly, namely g_canvas.h and g_all_guis.h). NB: m_pd.h and m_imp.h have remained unchanged.

Cheers!

Best wishes,

Ico

Hi Ico,

Regarding libraries/externals: I don't know if anyone else has experience an issue with the py (python) library with L2Ork pd-extended but when the binary is loaded it completely breaks/freezes PD. So much so I have to log out, log back in again and manually delete the py folder to get it to start up again.

Also Gridflow as mentioned previously causes crashes but not so hard as py. When I swapped the L2Orkt file to normal extended, I could use Gridflow in the new gui as normal- so perhaps the issue is not in the tk file but else where?

Of course the above could be due to my set up (or me just being dumb) so if anyone else has identical problems do me let know? - cheers!

On Sat, Nov 27, 2010 at 6:07 AM, Ivica Ico Bukvic ico@vt.edu wrote:

On Fri, 2010-11-26 at 21:26 -0500, Ivica Ico Bukvic wrote:

...

Another quick update includes following, mainly cosmetic fixes/improvements:

*made iemgui use default $select_color as defined in pd.tk while leaving legacy definition for IEM_GUI_COLOR_SELECTED color (as defined in g_all_guis.h) for other externals that may rely upon it *cleaned up bugs in mycanvas where label did not follow the object *cleaned up segfault on number2 when creating a label *modularized highlight nlet color and width and moved them to pd.tk *changed the way highlight nlet filters different objects and reverts their nlet color properly to original state (e.g. iemgui uses black as default whereas text objects use gray nlets

You can grab it from: http://l2ork.music.vt.edu/main/?page_id=56

Ugh, 20101127 is now out fixing two regressions. Namely,

1. segfault due to the way iemgui's implementation of universal color

did not allocate proper memory for the char array 2) stale GOP elements due to incorrect check for an open window

This latest snapshot should be considered 1st release candidate.

Cheers!

Ico

---

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

Hi Mathieu,

Thanks for this, I have done a trace back with the following output on the terminal :

(gdb) run Starting program: /usr/local/bin/pd -oss -channels 2 my-bug-test.pd [Thread debugging using libthread_db enabled] [New Thread 0xb6168b70 (LWP 5214)] <init> : Avifile RELEASE-0.7.48-100119-21:44-../src/configure <init> : Available CPU flags: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc nonstop_tsc extd_api <init> : 3200.00 MHz AMD Phenom(tm) II X2 555 Processor detected where

Program received signal SIGSEGV, Segmentation fault. 0x00000011 in ?? () (gdb) where #0 0x00000011 in ?? () #1 0x080a9665 in gobj_displace_withtag (x=0x8215790, dx=<value optimised out>, dy=0) at g_editor.c:70 #2 canvas_displaceselection (x=0x8215790, dx=<value optimised out>, dy=0) at g_editor.c:1913 #3 0x080a9a35 in canvas_motion (x=0x8215790, xpos=161, ypos=56, fmod=2) at g_editor.c:2102 #4 0x080ca856 in pd_typedmess (x=0x8215790, s=0x8136eb8, argc=3, argv=0xbffff08c) at m_class.c:792 #5 0x080ca43c in pd_typedmess (x=0x8211678, s=0x8136eb8, argc=3, argv=0xbffff08c) at m_class.c:813 #6 0x080cff0a in binbuf_eval (x=0x814d610, target=<value optimised out>, argc=0, argv=0x0) at m_binbuf.c:726 #7 0x080de1bf in socketreceiver_read (x=0x814d630, fd=6) at s_inter.c:560 #8 0x080ddb7a in sys_domicrosleep (microsec=<value optimised out>, pollem=<value optimised out>) at s_inter.c:198 #9 0x080de662 in sys_pollgui () at s_inter.c:862 #10 0x080d9681 in m_pollingscheduler () at m_sched.c:490 #11 m_mainloop () at m_sched.c:560 #12 0x080dcc09 in sys_main (argc=5, argv=0xbffff4e4) at s_main.c:310 #13 0x080e56cb in main (argc=5, argv=0xbffff4e4) at s_entry.c:32 (gdb) where #0 0x00000011 in ?? () #1 0x080a9665 in gobj_displace_withtag (x=0x8215790, dx=<value optimised out>, dy=0) at g_editor.c:70 #2 canvas_displaceselection (x=0x8215790, dx=<value optimised out>, dy=0) at g_editor.c:1913 #3 0x080a9a35 in canvas_motion (x=0x8215790, xpos=161, ypos=56, fmod=2) at g_editor.c:2102 #4 0x080ca856 in pd_typedmess (x=0x8215790, s=0x8136eb8, argc=3, argv=0xbffff08c) at m_class.c:792 #5 0x080ca43c in pd_typedmess (x=0x8211678, s=0x8136eb8, argc=3, argv=0xbffff08c) at m_class.c:813 #6 0x080cff0a in binbuf_eval (x=0x814d610, target=<value optimised out>, argc=0, argv=0x0) at m_binbuf.c:726 #7 0x080de1bf in socketreceiver_read (x=0x814d630, fd=6) at s_inter.c:560 #8 0x080ddb7a in sys_domicrosleep (microsec=<value optimised out>, pollem=<value optimised out>) at s_inter.c:198 #9 0x080de662 in sys_pollgui () at s_inter.c:862 #10 0x080d9681 in m_pollingscheduler () at m_sched.c:490 #11 m_mainloop () at m_sched.c:560 #12 0x080dcc09 in sys_main (argc=5, argv=0xbffff4e4) at s_main.c:310 #13 0x080e56cb in main (argc=5, argv=0xbffff4e4) at s_entry.c:32

Thanks again

Al On Sat, Nov 27, 2010 at 11:37 AM, Mathieu Bouchard matju@artengine.cawrote:

On Sat, 27 Nov 2010, ALAN BROOKER wrote:

Also Gridflow as mentioned previously causes crashes but not so hard as

...

py. When I swapped the L2Orkt file to normal extended, I could use Gridflow in the new gui as normal- so perhaps the issue is not in the tk file but else where?

If you (or someone else) can narrow down the l2ork<->gridflow problems, I could try to fix them.

Is it something happening mostly with the helpfiles, or also with something else ? Is it happening at startup, or later ?

What is the "L20rkt file" ?

---

| Mathieu Bouchard ------------------------------------- Aix-en-Provence

On Sat, 2010-11-27 at 20:44 +0100, András Murányi wrote:

with today's build, i got this upon clicking a [tgl] in a nested GOP (couldn't reproduce it from scratch)

Figured this one out--forgot to update one place in the g_numbox.c actually. It should be fine now.

That said, there are still a few gop problems when using gop within gop and I've traced these down to the fact that tcl/tk tends to recycle window_names for some reason (not sure if this is a part of the undo/redo/cut/copy/paste system or native tcl/tk). Anyone has any idea?

http://l2ork.music.vt.edu/main/?page_id=56

Cheers!

Small detail-- your 'Put' menu is tearoff-able.

-Jonathan

--- On Sun, 11/28/10, Ivica Ico Bukvic ico@vt.edu wrote:

From: Ivica Ico Bukvic ico@vt.edu Subject: Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...) To: "András Murányi" muranyia@gmail.com Cc: "PD List" pd-list@iem.at Date: Sunday, November 28, 2010, 12:18 AM

On Sat, 2010-11-27 at 20:44 +0100, András Murányi wrote:

...

with today's build, i got this upon clicking a [tgl]

in a nested GOP

...

(couldn't reproduce it from scratch)

Figured this one out--forgot to update one place in the g_numbox.c actually. It should be fine now.

That said, there are still a few gop problems when using gop within gop and I've traced these down to the fact that tcl/tk tends to recycle window_names for some reason (not sure if this is a part of the undo/redo/cut/copy/paste system or native tcl/tk). Anyone has any idea?

http://l2ork.music.vt.edu/main/?page_id=56

Cheers!

---

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

On Nov 28, 2010, at 11:11 AM, András Murányi wrote:

On Sun, Nov 28, 2010 at 7:47 AM, Jonathan Wilkes
jancsika@yahoo.com wrote: Small detail-- your 'Put' menu is tearoff-able.

...which is super cool, IMHO

Andras

Its one of those things that people love and hate. That's where GUI
plugins come in: people who love them can enable them with a simple
GUI plugin.

.hc

Programs should be written for people to read, and only incidentally
for machines to execute.

• from Structure and Interpretation of Computer Programs

On Nov 25, 2010, at 1:18 PM, Ivica Ico Bukvic wrote:

...

thanks for sharing. a couple of very minor remarks:

• • your webpage froze firefox/iceweasel on my eeepc the first time i

accessed it; i assume this is due to the animated tagcloud. is
there any conceptual reason for maaking a navigation aid eat 100% on 2 cores?

I wish I had an answer for you as the cloud is pure javascript and it works just fine on my MSI wind U100 netbook (single core with hyperthreading, so I guess you could call it Intel's fake 2 cores) as well as on my Android phone (where it is somewhat slow but does not impede the rest of the webpage). I would love to hear from the
others as well regarding this, because if this problem is more widespread I will look into altering/replacing it with something else.

...

once i managed to download it, i only played a few minutes with it,
so..

• • when releasing tarballs you should get rid of the .svn folders;

these hold a copy of all files, so you could reduce the size of the
unpacked bundle to about 50%

Unfortunately in my case it had no difference whatsoever as I've not used svn on this branch in some time. I believe the binaries are
what is causing the tarball to be as large as it is. At any rate, I will reupload it without the .svn folder.

...

• • the "magnifying glass" (i think you all refer to the "Patch cord

viewer" (or "cord inspector" how i would call it) by this term), is a very nice feature. what i find weird is, that i can only switch to "cord viewing" when
in edit mode; Ctrl-r in Run-mode simple doesn't do anything; i would
expect to switch my patch into run mode if needed

Well, this is the way original Sarlo's code works, so I haven't
given it much thought until now. Now that you brought it up, I feel like the current design makes more sense as the cord monitoring undoubtedly
saps some of the CPU and as such one would probably not want to run it in "runtime/performance" mode anyhow. OTOH if you are looking to monitor what passes through the cords, this in and of itself suggests you are likely troubleshooting something and as such are looking to edit the patch anyhow, so based on these two observations alone I would say the current behavior makes sense. Then again, I may be missing something here in which case I would certainly like to hear opinions from others as well.

All that said, I like your term better.

I think it makes a lot of sense to only have the Cord Inspector
available during Edit Mode, like Ico said, play/run mode should not
have other things drawing on the CPU.

...

• • the "inlet highlighting" (this looks more like a "magnifying

glass" to me) is a nice idea but it doesn't really help yet. e.g. with objects that have more inlets then available width (e.g. [pix_info]) you
still have the same problem as before (though a bit bigger); i also think
that the magnification amount is a bit too small, but this might be due
to my very small screen size (at first i wouldn't even notice a real difference then to the original connection cursor). it would
probably be a good idea to let the user change the amount of magnification)

Good idea. I'll add this to the todo (shouldn't be too hard--it really simply boils down to designing the edit menu and providing appropriate hooks). That said, what would be even better is simply adding a
tooltip that reflects which inlet/outlet is selected and what it does. This
was recently discussed and with the highlighting in place this would boil down to simply adding another two arrays to glist and filling them
with per-object descriptors (this last part being the biggest pain as it would have to be added pd-wide). In the interim, it could simply check for null entries and ignoring those that have not been implemented.

I think I'll take a stab at this one soon.

There is a tooltip patch in the patch tracker from Günter Geiger. Its
a good idea, but needs to be implemented differently, without changing
the core data structures. I don't remember the details, but I think
it shouldn't be hard to do.

...

• • why is the default selection color "orange/red"? is this a pd-

extended thing? for me this is very close to the error-indicating color "red" (e.g. when an object fails to create)

Because I find it hard to discern between blue and black (selected vs. deselected) on such thin lines that constitute most of the gui and
which occurs a lot more often than the red invalid objects. That said, I
will up the width on the red objects which should solve this problem.

Blue is the standard in all OSs I've used. But it wouldn't be hard to
make it a preference.

...

• • something i think is only inherited from pd-extended, but

whiich makes me shout out loud, is that when i start pd-l2ork it creates a "pd-externals" folder in my home directory. even if i don't do
anything apart from opening! i think this is _very_ rude.

This is indeed inherited from pd-extended and I think we need to hear from Hans on this one as I certainly wish to maintain as much pd-extended compatibility as reasonably possible. Hans?

Pd-extended aims to be newbie friendly. Creating this folder is one
example of that. I see no harm in Pd-extended creating this folder,
but those who don't like it rarely use Pd-extended anyway.

.hc

"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore

...

I think it makes a lot of sense to only have the Cord Inspector available during Edit Mode, like Ico said, play/run mode should not have other things drawing on the CPU.

sure. i was rather saying that i find it weird that if i am in edit mode and press Ctrl-R i get the cord inspector, whereas if i am in run mode and press Ctrl-R i get nothing. i would expect it to flip to edit mode and turn the inspector on. (similar to what happens if i press Ctrl-1 in run mode)

What you suggested is actually rather simple (boils basically down to one line of code). The difference between Ctrl+r and Ctrl+1 (object creation) is that former is a state, while latter a one-time event. So, for instance if in the current iteration you wish to have cord monitoring on at all times during the editing process it simply requires one Ctrl+R press at any point in time (regardless whether the editor is on or off), after which it stays on once again regardless of the editor's state so from that point on it only requires a Ctrl+e and you are ready to go. That said, rigging Ctrl+r to also open editor makes sense only in the case both the editor and Cord Inspector are off.

Latest version now includes this little alteration.

HTH

Ico

On Wed, 24 Nov 2010, Hans-Christoph Steiner wrote:

I think there are advantages to having the GUI be a separate process, and it would be worth exploring other ways of havning pd and pd-gui talk. Shared memory is one idea. Plus for things like arrays, the data could be sent as binary thereby skipping the string parsing aspect.

Look at how [#see] sends hex codes instead of decimals. Also, chop off the decimals you don't need. If you send ints instead of floats, and use a 12-bit range for stating y-position, every point could fit in 3 hex chars.

I say hex instead of base64 because base64 is not built-in in Tcl, therefore it's slower to handle.

But the only way to completely bypass all parsing is to use a 2nd socket. I haven't finished making something for that.

| Mathieu Bouchard ------------------------------------- Aix-en-Provence

Also notice that [flatspace/entry] has a nice cursor associated with resizing.

Noted. I will look into this once bug hunt is over. Thanks for the tip!

Another solution: you can also place a checkbutton labeled "Edit mode" directly on the menubar.

Yes, except personally I would prefer to keep the pd window as clean as possible.

Also, since we're talking about the menu changes: Since there is a "Find" menu, I think the "Edit" menu can be shortened by removing "Find", "Find again", and "Find last error".

Done. This will be included in the next tarball (even though it goes against Msft/Apple design guidelines.

Best wishes,

Ico

On Wed, 24 Nov 2010, Jonathan Wilkes wrote:

Well, you could also go the other way and just get rid of the "Find" menu altogether. It's just the redundancy I'd like to get rid of the redudancy. :)

Hi, this is James Martin Martin-James, from the Department of Repetitive Redundancy Department.

But seriously, if you come to Canada, be ready to encounter our jars of sauce mayonnaise sauce, chips Doritos chips, and fromage kraft cheese. It's a way of life.

| Mathieu Bouchard ------------------------------------- Aix-en-Provence

On Nov 24, 2010, at 7:37 PM, Jonathan Wilkes wrote:

--- On Wed, 11/24/10, Ivica Ico Bukvic ico@vt.edu wrote:

...

From: Ivica Ico Bukvic ico@vt.edu Subject: RE: [PD] call for testers for L2Ork iteration of pd- extended (based on 0.42.x branch) To: "'Jonathan Wilkes'" jancsika@yahoo.com Cc: pd-list@iem.at Date: Wednesday, November 24, 2010, 6:29 AM

...

Notice that both

[cyclone/Scope~] and [flatspace/entry] have a

...

bug: a sudden increase in height/width by about 5-10

pixels when you

...

initially drag to resize. This makes it

difficult if not

...

impossible to make minor size changes (especially

since there is no

...

Properties dialogue).

Good to know. I will look into this when I get there. Currently working on accelerating iemgui objects as well as exposing them to sarlo's highlighting magic.

Also notice that [flatspace/entry] has a nice cursor associated with resizing.

Ah yes, I forgot about that cursor in entry. I actually started
working on improving the [entry] widget, and that turned into the
tkwidgets library. I really should get the tkwidgets stuff into some
kind of usable release.

.hc

...

...

Wouldn't it be easier just to toggle the text for that

menu option

...

between "Edit mode" and "Run mode"? (That's what

they're called in

...

the manual.)

Sure. There are other options, too, like the one 0.43 and now l2ork version of 0.42 uses by changing option's background which works visually relatively well (albeit at the expense of consistency). This is however not the issue. The issue is finding out that after an hour of debugging the problem is not in you or your code but the toolkit you are using and in 2010 for a toolkit that has been around for more than a decade that is plainly sad.

Another solution: you can also place a checkbutton labeled "Edit mode" directly on the menubar.

Also, since we're talking about the menu changes: Since there is a
"Find" menu, I think the "Edit" menu can be shortened by removing "Find",
"Find again", and "Find last error".

...

...

How would you go about doing that?

A: Ugly path: Isolate pd<->gui hooks and port the entire thing to Qt.

B: Better (albeit more time-consuming) path: clean-up code first so that all objects can utilize the same gobj_<whatever> calls and then do the A: (which at that point won't be nearly as ugly or difficult to maintain).

FWIW, my first ever GUI app was RTMix I did back in 2001 and it was (and remains) the ugliest hack ever (basically I tried to learn how to program doing that app). Yet, the fact remains even in 2001 qt was way better than what Tk is today. Another advantage is avoiding socket bottlenecks as the entire thing could be done simply in C. License-wise it should be fine and cross-platform-wise miles ahead of Tcl/Tk. Heck, you could even throw in Qt for mobile devices for good measure since that is apparently hot item these days.

That said, I need some more time working with Pd code before I can undertake this. Perhaps more importantly, I just need a generous, uninterrupted chunk of time to do this.

Best wishes,

Ico

---

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

"[T]he greatest purveyor of violence in the world today [is] my own
government." - Martin Luther King, Jr.

On Wed, 24 Nov 2010, Jonathan Wilkes wrote:

Another solution: you can also place a checkbutton labeled "Edit mode" directly on the menubar.

Is this compatible with OSX ?

| Mathieu Bouchard ------------------------------------- Aix-en-Provence

I think 1 and 3 worked fine in osx.

Actually I also tried a fourth thing: Destroy the menubar when in 'Run mode'. (Not sure how that would work on osx, but in Gnome it sure makes an obvious distinction between modes!)

-Jonathan

In L2Ork iteration this functionality is available per-canvas and is toggled via l2ork_toggle_menubar abstraction. This way one can have a mix of guis having one and/or the other.

Cheers!

Ico

On Nov 29, 2010, at 4:16 PM, Jonathan Wilkes wrote:

--- On Mon, 11/29/10, Ivica Ico Bukvic ico@vt.edu wrote:

...

From: Ivica Ico Bukvic ico@vt.edu Subject: Re: [PD] call for testers for L2Ork iteration of pd- extended (based on 0.42.x branch) To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at Date: Monday, November 29, 2010, 9:11 PM

...

I think 1 and 3 worked fine in osx.

Actually I also tried a fourth thing: Destroy the menubar when in 'Run mode'. (Not

sure how that would

...

work on osx, but in Gnome it sure makes an obvious

distinction

...

between modes!)

-Jonathan

In L2Ork iteration this functionality is available per-canvas and is toggled via l2ork_toggle_menubar abstraction. This way one can have a mix of guis having one and/or the other.

Cheers!

Ico

Yes, I've been using a msg + [toxy] to do the same thing--
unfortunately you can see the menu getting deleted when you open the patch or make
it visible again.

I think you'll enjoy my two 0.43 plugins then, check out the
screenshot for "remove_menubar_from_canvases and canvas_menu_in_popup
plugins on Ubuntu"

http://puredata.info/dev/PdGuiRewriteScreenshots/

On Mac OS X, you shouldn't remove the menubar, because it then reverts
to the Wish.app menubar, which will only be confusing. But here's a
GUI plugin to remove the menubar for edit mode without it flashing (I
hope):

# this GUI plugin removes the menubars from any patch window that is # not in Edit Mode. Also, if a patch is switched to Run Mode, the # menubar will be removed.

proc setmenu_for_editmode {mytoplevel} { if {$::editmode($mytoplevel)} { $mytoplevel configure -menu $::patch_menubar } else { $mytoplevel configure -menu "" } }

# on Mac OS X, no windows have menubars, so no need to remove for 'aqua' if {$::windowingsystem ne "aqua"} { bind PatchWindow <FocusIn> {+setmenu_for_editmode %W} bind PatchWindow <<EditMode>> {+setmenu_for_editmode %W} }

pdtk_post "Finished loading menubar_only_in_editmode-plugin.tcl"

.hc

"We have nothing to fear from love and commitment." - New York Senator
Diane Savino, trying to convince the NY Senate to pass a gay marriage
bill

On Wed, 24 Nov 2010, João Pais wrote:

...

e.g. I am right now thinking it would be nice to have resizable cnv just by clicking on its bottom-right corner. Ditto for other visual iemgui objects. Another thing I would really like to see soon is ability to box-select patch cords. Then perhaps an undo doubly-linked list would be nice as well (although not sure how hard this would be).

basically many of the things possible in max should be implemented in pd.

This is that kind of thinking that led me to invent [#many]. I looked at their matrix of toggle-like things and told myself I should make something similar, except it would have a much shorter list of properties, and a possibility to connect plugins (using an extra inlet and outlet) so that any special behaviour can be user-specified. And then I wanted a variable element-class, not just toggle. And thus it was born.

Apart from that, many things can be made using [#see]-[#mouse] with various graphics processing in GF/GEM/PDP. [#see] displays a video in a patch, and the video can be tiny, generated, and rendered on demand (it's actually a picture viewer). This is most useful for high-color, pixel-oriented data, or really complicated vector data, perhaps.