game changer :D

2016-04-08 15:04 GMT-03:00 Ivica Ico Bukvic ico@vt.edu:

Yay!!!!!!! Great work, Jonathan!

On 4/8/2016 10:38 AM, Jonathan Wilkes via Pd-list wrote:

Hi list, Here are some binaries to test out the alpha 0 release for the GUI port of Pd-l2ork.

OSX doesn't have Gem or PDP, and both Windows and OSX are missing some Pd-l2ork-related externals.

Bug tracker is here: https://puredata.osuosl.org/jwilkes/purr-data/issues

Binaries are here: OSX x_64 - https://puredata.osuosl.org/purr-data-binaries/osx-64-alpha0/repository/archive.zip?ref=master https://puredata.osuosl.org/purr-data-binaries/osx-64-alpha0/repository/arch... Ubuntu 15.10 x_64 - https://puredata.osuosl.org/purr-data-binaries/ubuntu-15.10-64-alpha0/repository/archive.zip?ref=master https://puredata.osuosl.org/purr-data-binaries/ubuntu-15.10-64-alpha0/reposi... Ubuntu 14.04 x_64 - https://puredata.osuosl.org/purr-data-binaries/ubuntu-14.04-64-alpha0/repository/archive.zip?ref=master https://puredata.osuosl.org/purr-data-binaries/ubuntu-14.04-64-alpha0/reposi... Ubuntu 14.04 i386 - https://puredata.osuosl.org/purr-data-binaries/ubuntu-14.04-32-alpha0/repository/archive.zip?ref=master https://puredata.osuosl.org/purr-data-binaries/ubuntu-14.04-32-alpha0/reposi... Debian Jessie x_64 - https://puredata.osuosl.org/purr-data-binaries/debian-jessie64-alpha0/reposi... Debian Jessie i386 - https://puredata.osuosl.org/purr-data-binaries/debian-jessie32-alpha0/reposi... Windows 32-bit - https://puredata.osuosl.org/purr-data-binaries/win32-alpha0/repository/archive.zip?ref=master https://puredata.osuosl.org/purr-data-binaries/win32-alpha0/repository/archi...

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

---

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

On Friday, April 8, 2016 5:20 PM, Simon Iten itensimon@gmail.com wrote:

great! looks so smooth.  on osx 10.11 i get a: basename is load-meter.pd path is /Users/doc/7.stuff/tools error: load-meter.pd: read failed when trying to open the load-meter.

Same on Windows.  I added an issue to the bug tracker. -Jonathan

Hi Marco,

-) apart Gem and Pdp that I understand are "properly" not loaded, toxy, flib, flatspace and pidip are not loaded (maybe wanted, just a report...)

Which operating system and arch are you using?

-) [array] and all stuff related [array define array1] are not created: array ...couldn't create

I haven't ported [array] to Pd-l2ork yet.

-) so I put from menu an array; the first one that I created doesn't appear even if prints his name on console. the second one appears, but it starts on console to print:

This could be a bug.  When you let me know which OS I'll look further.

Those are old debugging errors that I'll remove for the next alpha.  I went ahead and made a bug report to remove them. -Jonathan

On Monday, April 11, 2016 2:05 PM, Marco Matteo Markidis <mm.markidis@gmail.com> wrote:

Hi Jonathan, amazing work. Something that I see during some trial:-) apart Gem and Pdp that I understand are "properly" not loaded, toxy, flib, flatspace and pidip are not loaded (maybe wanted, just a report...)-) [array] and all stuff related [array define array1] are not created: array ...couldn't create-) so I put from menu an array; the first one that I created doesn't appear even if prints his name on console. the second one appears, but it starts on console to print: Old command at g_array.c:1355:pdtk_select_all_gop_widgets .x101850c00 100828000 0 and: Error: couldn't find iemgui prop group for y-scaleError: couldn't find iemgui prop group for x2 Error: couldn't find iemgui prop group for y-pix Error: couldn't find iemgui prop group for y-margin-) I finally loaded my sample and it exceeds the array limit (but I see something related on bug tracker) Moreover, I try some mine external and they works properly...So, again amazing work and hope that my report can be useful. Maybe you already know this stuff and this is a waste of time: in this case sorry! Best regards, Marco 2016-04-08 23:51 GMT+02:00 Jonathan Wilkes via Pd-list pd-list@lists.iem.at:

On Friday, April 8, 2016 5:20 PM, Simon Iten itensimon@gmail.com wrote:

great! looks so smooth.  on osx 10.11 i get a: basename is load-meter.pd path is /Users/doc/7.stuff/tools error: load-meter.pd: read failed when trying to open the load-meter.

Same on Windows.  I added an issue to the bug tracker. -Jonathan

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

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

Great.  I added some bugs to the tracker for these and will investigate them. -Jonathan

On Tuesday, April 12, 2016 10:15 AM, Marco Matteo Markidis <mm.markidis@gmail.com> wrote:

Hi Jonathan, I have a OSX 10.10 (Yosemite). Thank you for your work. Marco 2016-04-11 21:34 GMT+02:00 Jonathan Wilkes jancsika@yahoo.com:

Hi Marco,

-) apart Gem and Pdp that I understand are "properly" not loaded, toxy, flib, flatspace and pidip are not loaded (maybe wanted, just a report...)

Which operating system and arch are you using?

-) [array] and all stuff related [array define array1] are not created: array ...couldn't create

I haven't ported [array] to Pd-l2ork yet.

-) so I put from menu an array; the first one that I created doesn't appear even if prints his name on console. the second one appears, but it starts on console to print:

This could be a bug.  When you let me know which OS I'll look further.

Those are old debugging errors that I'll remove for the next alpha.  I went ahead and made a bug report to remove them. -Jonathan

On Monday, April 11, 2016 2:05 PM, Marco Matteo Markidis <mm.markidis@gmail.com> wrote:

Hi Jonathan, amazing work. Something that I see during some trial:-) apart Gem and Pdp that I understand are "properly" not loaded, toxy, flib, flatspace and pidip are not loaded (maybe wanted, just a report...)-) [array] and all stuff related [array define array1] are not created: array ...couldn't create-) so I put from menu an array; the first one that I created doesn't appear even if prints his name on console. the second one appears, but it starts on console to print: Old command at g_array.c:1355:pdtk_select_all_gop_widgets .x101850c00 100828000 0 and: Error: couldn't find iemgui prop group for y-scaleError: couldn't find iemgui prop group for x2 Error: couldn't find iemgui prop group for y-pix Error: couldn't find iemgui prop group for y-margin-) I finally loaded my sample and it exceeds the array limit (but I see something related on bug tracker) Moreover, I try some mine external and they works properly...So, again amazing work and hope that my report can be useful. Maybe you already know this stuff and this is a waste of time: in this case sorry! Best regards, Marco 2016-04-08 23:51 GMT+02:00 Jonathan Wilkes via Pd-list pd-list@lists.iem.at:

On Friday, April 8, 2016 5:20 PM, Simon Iten itensimon@gmail.com wrote:

great! looks so smooth.  on osx 10.11 i get a: basename is load-meter.pd path is /Users/doc/7.stuff/tools error: load-meter.pd: read failed when trying to open the load-meter.

Same on Windows.  I added an issue to the bug tracker. -Jonathan

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

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

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

I will let Jonathan answer the bulk of your questions pertaining to the latest GUI port. As far as GUI objects being offset, pd-l2ork has had the -legacy startup flag for some time now that ensures that all the patches will render according to legacy GUI positioning.

Best,

2016-04-12 13:05 GMT-03:00 Ivica Bukvic ico@vt.edu:

pd-l2ork has had the -legacy startup flag for some time now that ensures that all the patches will render according to legacy GUI positioning.

just so I get it, but then pd-l2ork patches won't load accordingly, right?

cheers

> On Tuesday, April 12, 2016 11:59 AM, Roman Haefeli <reduzent@gmail.com> wrote:

On Fri, 2016-04-08 at 14:38 +0000, Jonathan Wilkes via Pd-list wrote:

...

Hi list, Here are some binaries to test out the alpha 0 release for the GUI port of Pd-l2ork.

Wow.. impressive work you've done and I think I'm not even remotely able to grasp what it meant to achieve this. I very much like its native look (I checked on Ubuntu 14.04). Also the GUI tab in the preferences dialog, very neat. And the canvas zoom is probably going to be _the_ killer feature with all the hi-res displays coming up.

If you have a chance, do check out doc/4.data.structures/pd-l2ork/ds-tutorialsas well.  It's still under heavy development, but I think you'll find the API allows you to do 2d visualizations with a lot less work than the vanilla API.  Part of that has to do with affine transformations, which includes zooming (well, scaling)-- that's why I mention it here.

Some observations (from Ubuntu 14.04 i386):

* For a true vanilla experience, it'd be nice if the GUI preset

'vanilla' would use bold fonts.

Added to tracker.  I have the feeling I didn't do this because the bold style probably changes the line width, which makes it a harder problem than just adding a line of css.  But I'll look into it.

• I sometimes have to click on Menus twice for the selected item to show

up. I couldn't figure out a reliable pattern. Affected entries:   'Media->Test Audio and Midi' or 'Edit -> Preferences' This is a bug in nw.js.  It's been reported and investigated, and will hopefully get fixed soon.

• I can't load many of my patches in this nw-version of Pd-l2ork. When I

do so, the patch canvas never appears and I get repeating messages   'watchdog: signaling pd..' on stderr. The process 'nw' uses 100% of a   core and I have to kill pd-l2ork. Some simple patches work fine and I   haven't figured out a pattern of what kind of patches are affected   which are not. However, the behaviour of a certain patch is consistent   (either it loads always ok or it never does so).   UPDATE: Not true. It just takes that much time to load the patch. The   one I just loaded took more than 2 minutes to load. You can see it even with the loadmeter on slower machines-- each additional Pd object triggers a layout recalculation, and that can result in jank. But I think I've got a fix for it. Email me a worst-case patch and I'll test.

What version of Pd-vanilla is this based on? Or is not related to

vanilla anymore? I stopped caring about Pd-l2ork when I figured it contains some fixes that shifts position of iemguis around. This renders a lot of my patches unusable because they are not displayed in the GOP area anymore. I'd love if patches would work in both flavors, but right now it seems as a patch author you need to decide one. Try starting up with the "-legacy" flag and tell me if they display properly. This is a transitional flag-- what I want to do is add a flag to t_canvas so that this "just works" for you and "just works" for Pd-l2ork gops going forward.  (And just have some simple mass import for Pd-l2ork gops created in the interim.)

In the meantime, let me know any of your gop abstractions that don't display correctly with -legacy and I'll file a bug and investigate.

Is it correct that externals for Pd-l2ork are binary-incompatible with

externals built for Pd-vanilla? I'm just interested to know, maybe this isn't such a huge issue, since Pd-l2ork has so many externals pre-compiled. Two related issues:1. I am porting gui externals manually to nw.js.  In these cases binary compatibility is irrelevant.2. AFAICT nobody has had sufficient interest to test whether or not Pd-l2ork and Vanilla are binary compatible. So I think I'll just blithely claim they are 100% binary compatible.  If anybody finds otherwise, I'll file a bug. -Jonathan

Roman

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

> On Tuesday, April 12, 2016 12:03 PM, Roman Haefeli <reduzent@gmail.com> wrote:

Some observations (from Ubuntu 14.04 i386):

• For a true vanilla experience, it'd be nice if the GUI preset

'vanilla' would use bold fonts.

I just looked at this.  The bold font weight is _slightly_ wider.  But I had to create an object that spans the width of my laptop screen before the right edge of the text finally ate up the right margin and touched the box border. Bigger issue is that "DejaVu Sans Mono Bold" is actually a separate font in a separate file.  I'm utilizing the CSS @fontface feature in order not to have to install the font to the OS, which is great.  But it means I'd have to package and ship the bold font file, just to accommodate this strange aesthetic of everything-is-bold-therefore-nothing-is-important.

However, I hate reading the arrogant "won't fix" resolution on bug reports, so I'll commit to addressing this issue if someone buys me a burrito.

• I sometimes have to click on Menus twice for the selected item to show

up. I couldn't figure out a reliable pattern. Affected entries:   'Media->Test Audio and Midi' or 'Edit -> Preferences' This was just fixed in the latest update to nw.js, so it will be fixed in the next alpha.

• I can't load many of my patches in this nw-version of Pd-l2ork. When I

do so, the patch canvas never appears and I get repeating messages   'watchdog: signaling pd..' on stderr. The process 'nw' uses 100% of a   core and I have to kill pd-l2ork. Some simple patches work fine and I   haven't figured out a pattern of what kind of patches are affected   which are not. However, the behaviour of a certain patch is consistent   (either it loads always ok or it never does so).   UPDATE: Not true. It just takes that much time to load the patch. The   one I just loaded took more than 2 minutes to load.

Just an FYI-- this was due to Pd-l2ork not (yet) having the [text] object, which had the side-effect of causing Roman's patch to trigger an endless [until] loop. However, I believe I'm still thrashing the layout when mapping a patch in the GUI, so it's definitely slower than it could be atm. -Jonathan