Purr Data Beta 3!

This is the GUI port of Pd-l2ork from tcl/tk to nw.js. Canvas zooming, svg-based data structure drawings, GUI theming, and more...

• fixed "stale pointer" bug when re-opening a subpatch on a scalar that has an event handler
• added ds tutorial for field parameters
• removed more debugging messages
• updated ds tutorials, add coords tutorial for ds shapes
• fixed stroke-linecap "square" style
• use standard "d" attribute instead of "data" for setting svg data
• fixed for the open dialog
• added feature to format path data into a FUDI message
• added table of contents to help browser
• fixed crasher with scalar dialog handling of vector data
• fixed data properties dialog positioning
• fixed typos in drawnumber_vis that caused sizing bug
• check scroll bars after zooming the canvas
• allow doc/ and extra/ prefixes to search a particular directory (instead of
  a natural language search)
• allow browsing the docs using native file dialog
• fixed small bugs in the doc search engine
• fixed font size bug on newer versions of Gnu/Linux
• fixed pdogg dependency, bump version to 0.25.2
• fixed regression with broken object box getting recreated with a superfluous cord connection
• now using homebrew on OSX instead of macports (faster install time, smaller install size)
• fixed stroke-dashoffset to stick when scalar is re-vis'd
• lots of other small fixes here and there...

This is a beta release, so please report lots of bugs to
https://git.purrdata.net/jwilkes/purr-data/issues

Binaries:

Debian Jessie 32-bit

Debian Jessie 64-bit

Ubuntu 14.04 32-bit

Ubuntu 14.04 64-bit

Ubuntu 16.04 64-bit

Windows with 64-bit GUI

Windows with 32-bit GUI

Added an rpi raspbian binary:
https://git.purrdata.net/jwilkes/purr-data-binaries/blob/master/purr-data-armv7l-raspbian-beta3.deb

Thanks for what you're doing. Is it available in homebrew already and if yes, what's the name of the package?

Thank you

@tuborgman said:

Thanks for what you're doing. Is it available in homebrew already and if yes, what's the name of the package?

Thank you

I meant that I use homebrew in the build instructions on the site. This makes it much faster for people to build Purr Data themselves. I distribute the binaries from the links above-- I'm not sure what it would add to actually distribute Purr Data over homebrew. What would the benefits be?

Also, the next beta will use a dmg installer on OSX.

@jancsika Thank you. Dmg installer is just fine.

Do you have any plans for custom keyboard shortcuts? I am struggling to set something up in vanilla through tlc, but all those handles would disappear I guess in Purr Data? My biggest UI issue is actually having to mouseclick and modifier press so much. It hurts my hands when trying to patch fast! Would really love to have max-style shortcuts for objects, not using a modifier key: n for new object, m for message, b for bang, f for number, c for comment, t for toggle, s for slider. It's fast, and easy to remember.

@abcdaniel said:

Do you have any plans for custom keyboard shortcuts? I am struggling to set something up in vanilla through tlc, but all those handles would disappear I guess in Purr Data? My biggest UI issue is actually having to mouseclick and modifier press so much. It hurts my hands when trying to patch fast! Would really love to have max-style shortcuts for objects, not using a modifier key: n for new object, m for message, b for bang, f for number, c for comment, t for toggle, s for slider. It's fast, and easy to remember.

I'd like to have custom key bindings. I haven't figured out an interface for them yet, so if you have any ideas let me know.

However, that only solves half of your issue. You still have to use mouse clicks to draw all the lines. I've got an idea for navigating the patch and creating lines by leveraging canvas "Find", but it's still in the planning stage.

In the meantime, you could take advantage of the following speedups in Pd-l2ork/Purr Data:

1. If you select two objects-- like [unpack 0 0 0] and [pack 0 0 0]-- then make a connection between them, the rest of the inlet/outlet pairs will get a connection between them.
2. If you want to connect one object to many objects-- let's say connecting [bng] to a bunch of message boxes-- select the message boxes and make a connection from [bng] to the first one. An additional connection will be made to the other message boxes.
3. If you want to connect many objects to one inlet, select the many objects, make a connection to the one object, and the rest will be connected to the same inlet.

Hope that helps

Thanks for the tips on the patchcords! Those are great. I would also love to have click output - release mouse button - drag - click input. That click - hold - drag - click is less than ideal ergonomically imho.

Quick idea for interface to start with: Have a panel/window of some sort listing the menuitems with shortcuts, with an inputbox of some sort next to each, prepopulated with the shortcut. User puts his cursor in the inputbox and type the shortcut. If shortcut is already in use, error message: "This shortcut is in use by item x, do you want to replace that shortcut with this?" Y/N.

Special sauce for interface is using the autocompletion engine (which there will beat some point, I guess?) to find objects to make a shortvut for. Have a + button on the bottom of the interface panel/window, that opens a new box, where you can search for objects by typing, next to it an inputbox of some sort to record the shortcut.

@abcdaniel said:

Thanks for the tips on the patchcords! Those are great. I would also love to have click output - release mouse button - drag - click input. That click - hold - drag - click is less than ideal ergonomically imho.

I don't have access to Pd atm, but could you try hovering over an outlet and doing <ctrl> plus click (or possibly <cmd> plus click on osx)? I think that will allow you to release the mouse button and get a dangling wire that you can connect to another inlet.

Quick idea for interface to start with: Have a panel/window of some sort listing the menuitems with shortcuts, with an inputbox of some sort next to each, prepopulated with the shortcut. User puts his cursor in the inputbox and type the shortcut. If shortcut is already in use, error message: "This shortcut is in use by item x, do you want to replace that shortcut with this?" Y/N.

That sounds pretty clear. There are some ugly implementation details with the menus that make changing the shortcuts in the running instance hard, but hopefully we can figure out a way around that.

Special sauce for interface is using the autocompletion engine (which there will beat some point, I guess?) to find objects to make a shortvut for. Have a + button on the bottom of the interface panel/window, that opens a new box, where you can search for objects by typing, next to it an inputbox of some sort to record the shortcut.

The question on this is: what should the autocomplete draw from? All the thousands of classes in the externals? Just the internal classes?

I think it is more important to have good autocompletion first. cmd+1, a few letters then tab is nearly equal to a shortcut for me. I liked the autocompletion plugin for pd-extended because it was possible to make it search for objects in libraries - show all objects in a library or reverse: which libraries have this object ? I also added my own abstractions and their subfolders. This keeps me from making the same abstractions several times, and find old stuff again.
-> A file-browsing autocompletion would be nice, I don't know if this slows it down.

Anyway I agree that it would be nice to have the possibility to change or create shortcuts at least for menu items, zoom,... -very useful for users with different keyboard layouts, like german, french,...

@royal_orchestra said:

I think it is more important to have good autocompletion first. cmd+1, a few letters then tab is nearly equal to a shortcut for me. I liked the autocompletion plugin for pd-extended because it was possible to make it search for objects in libraries - show all objects in a library or reverse: which libraries have this object ? I also added my own abstractions and their subfolders. This keeps me from making the same abstractions several times, and find old stuff again.
-> A file-browsing autocompletion would be nice, I don't know if this slows it down.

I can index files for the search browser fairly quickly with Purr Data. But quickly in that context means
less than a second. In the context of typing a name that is unfortunately too much latency to be usable.
There are probably ways around that but it requires more complexity in the code.

But I agree that autocomplete is a pretty important feature. I'm using it all the time in devtools when I debug Purr Data, so...

less than a second. In the context of typing a name that is unfortunately too much latency to be usable.

Typing the name of a library, a folder or the first few letters of an object, hitting tab- or arrow-key,
wait <1 second and get an popup-menu with suggestions to choose from - would be ok for me.

I'm looking forward for your solution

@jancsika said:

@abcdaniel said:

Quick idea for interface to start with: Have a panel/window of some sort listing the menuitems with shortcuts, with an inputbox of some sort next to each, prepopulated with the shortcut. User puts his cursor in the inputbox and type the shortcut. If shortcut is already in use, error message: "This shortcut is in use by item x, do you want to replace that shortcut with this?" Y/N.

That sounds pretty clear. There are some ugly implementation details with the menus that make changing the shortcuts in the running instance hard, but hopefully we can figure out a way around that.

Did a mockup of a such a shortcut interface: http://brynspace.se/demo/custom-shortcuts.html.
I added a "Custom" section, where you could utilize pd's simple text based file format to do any kind of shortcut and even snippets. Some text parsing would be required, to exclude coordinates for single objects. Objects that come with arguments are created as is, objects without arguments are created, and textcurser placed within. Snippets need to have coordinates recalculated relative to their new placement.
Could start implementing the custom part as a new feature, if getting access to the menues is messy, maybe?
Not all css nor js nor html is perfect…

To elaborate some more, inside a regular pd patch there could be a "Copy as text" option (or is that default? Copy on my mac doesn't transfer to the global pasteboard). Copy as text is useful also for posting stuff on forums. Copy as text, paste in the custom shortcut. Onviously, if all rendering is based on HTML, the custom shortcut boxes could also just render tha actual boxes, but that I guess is down the line, if this custom idea sounds good in any way.

@abcdaniel That's a nice mockup! It would be great to have something like that in the GUI preferences tab.

There are unfortunately some issues with the keyboard shortcuts in the nw.js toolkit atm. I have a lot of workarounds to get things working the same across windows, osx, and linux. So there will need to be some amount of refactoring to make it easy enough to do user-configurable shortcuts.

@jancsika Thanks! Feel free to use any of it. Having the flexibility of shortcuts for empty single objects, object with predefined arguments and for snippets at the same place, I think would be awesome and a one up on sister Max.

Just feel the need to type this out loud, though I'm sure it is way overstated: If you are actively editing an object, any shortcut that is a single letter or number key should be temporarily diabled. That is not the case for the tcl/tk examples for custom shortcuts for vanilla Pd, and that blows my mind as an oversight. Ok, wrote that, hope that's ok.

So, dangling patchcords… is that possible/desireable in Purr Data? The suggested shortcut (cmd/ctrl while clicking) didn't work. I don't really want to hit a modifier to get a dangling cord, either. I feel strongly about those small ergonomics, click-drag-release is suboptimal, especially with a trackpad. The current click-drag-release behaviour could still be there, and is really fast in some cases, but clicking and releasing would get a dangling cord. Hitting esc would stop the dangling cord, but you rarely start a cord and then change your mind, so the escape thing would not be that much in use, and not be that much inconvenient for a die hard click-drag-release user. Click and release would also make it possible to do segmented patchcords down the line.