purr-data merge requestshttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests2017-04-18T03:35:02Zhttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/97debuild: re-add missing bash completion file2017-04-18T03:35:02ZAlbert Gräfdebuild: re-add missing bash completion filehttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/98debuild: Bump nw.js version to 0.22.0.2017-04-30T20:04:28ZAlbert Gräfdebuild: Bump nw.js version to 0.22.0.Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/99debuild: Bump nw.js version to 0.22.1.2017-05-05T13:03:50ZAlbert Gräfdebuild: Bump nw.js version to 0.22.1.Following suit once again after rev. 45544edfadcaef3a7cdd7e6f26c0a21492b54742.Following suit once again after rev. 45544edfadcaef3a7cdd7e6f26c0a21492b54742.Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/96Update cyclone2017-06-04T18:07:06ZJonathan WilkesUpdate cycloneanother library update. This one is more complex as we're using a git submodule and a git.purrdata.net mirror to pull the new version.
This branch has an updated externals/Makefile and builds the new version correctly (CI will show wh...another library update. This one is more complex as we're using a git submodule and a git.purrdata.net mirror to pull the new version.
This branch has an updated externals/Makefile and builds the new version correctly (CI will show whether it does so on all platforms.)
Once that's confirmed, the gui port of `Scope~` needs to be merged with the new `scope~.c` code. This will be difficult for a few reasons:
* Purr Data has the extra `displace_withtag` widget behavior
* the old tcl/tk calls need to be preserved
* Purr Data's current `Scope~` doesn't have a dialog while pd-cyclone's `scope~` does.
Probably it's best to do the following:
1. abstract out the raw tcl code into function calls. Then we can have an entire section of ifdef'd functions that call gui_vmess for pd-l2ork and a separate one for sys_vgui of Pd-vanilla.
2. ifdef in the extra widgetbehavior into the code
3. Leverage (and improve) the "dialog_external" interface of Purr Data to create the dialog. It's a bit ugly and needs some work but it should provide a decent stopgap for now.https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/104dropdown menu improvements2017-06-25T16:34:28ZJonathan Wilkesdropdown menu improvementsThese are improvements based on some feedback from user "sensn" on the Pd forum:
>one good thing about [dropdown] ... if you got a lot of entries it will automatically create a scrollbar.
But this scrollbar doesn't work as expected.
...These are improvements based on some feedback from user "sensn" on the Pd forum:
>one good thing about [dropdown] ... if you got a lot of entries it will automatically create a scrollbar.
But this scrollbar doesn't work as expected.
Works now with !104
> If you left-click the scrollbar to do some scrolling - dropdown will collapse and select one of the first entries. clicking the up-down buttons will do the same.
Fixed in !104
> Using the mousewheel to scroll down (when mouse is over the scrollbar) will work but if you move the mouse to the left to select an entry on the bottom of the list, dropdown will scroll up again.
Fixed in !104
> If your patch-canvas has scrollbars and the dropdown-object has scrollbars and you try to select an entry with your up/down-arrow keyboardkeys, both the canvas and the dropdown will scroll. Moreover the selection of dropdown will jump 2 entries on one keypress.
Fixed in !104
> Another thing i noticed: If you place the drop down on the bottom of a patch-window and you try to do a selection, the dropdown object doesn't "drop-up" so it's hard to select something.
Fixed in !104
> It's nice to have mousewheel in a gui object now. would be cool for sliders too. Any chances we could have mousewheel for the ds-draw command? (just like mouseover 1..)
Separate issue: #337
> Tof/ menubutton worked differently, it would open up the drop down list independently from the parent window.
This would be possible by using `<select>`. But then we'd give up control of the display of the object-- exactly how wide and high. Additionally styling would be determined by the OS. One could get around this by making that element invisible and stacking it on top of the SVG. But then you'd have to also disable it in Edit Mode-- otherwise the menu would trigger on an Edit Mode click which isn't the desired behavior. More of a pain for a small usability improvement.
Thus, all relevant items have been addressed. Now we just need to test-- especially under Windows and OSX. Then this can merged.Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/105Windows ci updates2017-07-09T15:42:54ZJonathan WilkesWindows ci updatesA few changes to get the Windows runner operationalA few changes to get the Windows runner operationalJonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/103attempt to fix #330: Soundfiler inefficiency (10x memory usage in Purrdata ve...2017-07-10T03:52:28ZJonathan Wilkesattempt to fix #330: Soundfiler inefficiency (10x memory usage in Purrdata versus Pd-vanilla)Don't multiply requested memory size by sizeof(char*)
Edit: The original commit message that added these changes mentioned a memory error detected by valgrind. So we should probably run Purr Data like this to test for regressions:
...Don't multiply requested memory size by sizeof(char*)
Edit: The original commit message that added these changes mentioned a memory error detected by valgrind. So we should probably run Purr Data like this to test for regressions:
```
valgrind pd-l2ork -nrt
```
(The "-nrt" flag to suppress distracting "pd-watchdog" messages to the console.)
This needs to be thoroughly tested, with a few cases in mind:
* changing the contents of object/message boxes
* using dollarsigns in messages, especially `$@`
* mixing in some unicode characters
* any other stress tests we can think ofhttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/102Soundfiler fixes2017-07-11T02:11:10ZJonathan WilkesSoundfiler fixesThis merge request ports a number of improvements to d_soundfiler.c, d_array.c, and a few other files from Pd Vanilla.
Most of the improvements have to do with reading aiff and wav files, as well as some added checks for reading and w...This merge request ports a number of improvements to d_soundfiler.c, d_array.c, and a few other files from Pd Vanilla.
Most of the improvements have to do with reading aiff and wav files, as well as some added checks for reading and writing array values.
Affected classes are `[tabread4~], [soundfiler], [readsf~], [writesf~], garrays`, and possibly some others.
Each commit in the merge lists the details from the original Pd Vanilla commit plus the hash.
Tests - I did a quick test just with the soundfiler-help.pd. Should probably do the same for the rest of the classes above before merging.https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/101WIP: Update cyclone2017-07-21T17:05:42ZJonathan WilkesWIP: Update cycloneChange from miXed/cyclone to the new pd-cyclone version of cyclone.
Blockers:
* namespace prefixes for classes like `[!-]` don't currently work
* help patches for those same classes use the currently unsupported `[cyclone/comment]` ins...Change from miXed/cyclone to the new pd-cyclone version of cyclone.
Blockers:
* namespace prefixes for classes like `[!-]` don't currently work
* help patches for those same classes use the currently unsupported `[cyclone/comment]` instead of iemgui labelshttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/106Soundfiler bugfixes2017-07-11T02:54:39ZJonathan WilkesSoundfiler bugfixesAnother soundfiler bugfix branch to correct the previous one which was accidentally build atop the still unmerged pd-cyclone branch.Another soundfiler bugfix branch to correct the previous one which was accidentally build atop the still unmerged pd-cyclone branch.Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/107add some convience classes for external mouse tracking2017-07-18T22:06:52ZJonathan Wilkesadd some convience classes for external mouse trackingadd some rudimentary mouse tracking objects so that the questionable C code in the various mouse-related classes can be replaced with abstractions:
* mouseclick - track mouseup and mousedown state, including position on canvas at the ...add some rudimentary mouse tracking objects so that the questionable C code in the various mouse-related classes can be replaced with abstractions:
* mouseclick - track mouseup and mousedown state, including position on canvas at the time of click
* mousemotion - track mousemove events sent from the GUI. Relative to the DOM window over which the mouse is currenty being moved
* mousewheel - track mousewheel motion. (Not implemented yet, but a user requested it and it should be easy enough.)
These classes can track mouse actions across *all* open canvas windows. For coordinates they return x/y positions relative to the DOM window over which the mouse is currently being tracked.
IMO this is an inferior interface to the mouse methods for data structures that I implemented. The relevant `[draw]` methods only work on a specified area of the canvas and are thus less prone to getting in the way of audio computation. Also, the `[draw]` methods can be used to turn mouse events like mousemove on and off at will (or even selectively turned on for only certain scalar instances and not others). `[mousemotion]` will inescapably try to send output for every mousemove event. (I could add a method to toggle this, but canvas_motion would *still* need to dispatch to all receivers so that they could check their own toggle state, which probably defeats the purpose...)
Still, there are probably lots of tutorials in the wild built atop legacy externals that want to just mindlessly poll mouse position. If the idea is to just map freq./amp./etc. to mouse position, they serve their purpose. Thus, it's easier to just build abstractions around these new mouse classes than it would be to re-implement every ad-hoc Pd<->GUI interface in these externals.
I haven't tested the performance of the changes to canvas_motion in g_editor.c yet. As long as none of these mouse objects exist the affect should be negligible (just a check for existence, a a pointer dereference, and a one-time gensym). Once there is a `[mousemotion]` there is an additional method call to it for *every* tick of the mouse.Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/109WIP: fix for #348, plus compatibility codepath and Pd Vanilla version bump2017-07-20T03:20:43ZJonathan WilkesWIP: fix for #348, plus compatibility codepath and Pd Vanilla version bumpThis fixes a bug with `[wrap~]` and bumps the version to 0.48 to trigger the new code path.
To my eye the bug looks like a deterministic one. Miller says it's not on his Fedora box. If anyone can explain what would trigger undefined b...This fixes a bug with `[wrap~]` and bumps the version to 0.48 to trigger the new code path.
To my eye the bug looks like a deterministic one. Miller says it's not on his Fedora box. If anyone can explain what would trigger undefined behavior in the old code path I'll remove it entirely.
Also-- we probably need a better process for choosing when to bump Pd Vanilla version number. Here, it's misleading because we haven't added all the other changes from Pd Vanilla. But for this compatibility fix it's the easiest way to do it.Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/111Save the defaults on OSX if the user prefs don't exist yet (fixes #339)2017-07-27T21:56:17ZAlbert GräfSave the defaults on OSX if the user prefs don't exist yet (fixes #339)Save the defaults on OSX if the user prefs don't exist yet, in order to avoid losing them later when saving the recent files list (fixes #339).Save the defaults on OSX if the user prefs don't exist yet, in order to avoid losing them later when saving the recent files list (fixes #339).Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/112throttle gui_canvas_get_scroll instead of debouncing2017-08-07T00:34:12ZJonathan Wilkesthrottle gui_canvas_get_scroll instead of debouncingwhile debouncing this call can save re-layouts of the DOM, with indeterminate
streams of redraws coming from Pd it can result in no re-layouts at all. In
the case where a user opens a subpatch that has a redraw triggered by a
[metro 200]...while debouncing this call can save re-layouts of the DOM, with indeterminate
streams of redraws coming from Pd it can result in no re-layouts at all. In
the case where a user opens a subpatch that has a redraw triggered by a
[metro 200] object, there may not even be an initial layout. This can result
in the patchsvg never getting its viewBox set and appearing not to display
at all.
One workaround could be to do an initial call immediately after mapping the
window, but there are still cases (like resizing a window or adding objects)
that could result in putting off a needed re-layout for too long.
So instead of debouncing, we throttle. This means there will only be a
single call every 250ms (or whatever value we want), but that call is
_guaranteed_ to happen at the end of the chosen duration. So for a stream
of redraws coming from a [metro 200] we'll get a re-layout every 250ms. That's
more expensive than putting them off indefinitely, but obviously more
responsive and usable.
Ideally we would send a do_getscroll _first_ and then wait 250ms. That would
result in a more responsive UX-- as it is the 250ms makes the initial window
rendering appear sluggish. Unfortunately there's still some kind of race
between the rendering of the window menu and the window size measurements
reported by the DOM API-- if we measure too early the vertical measurement is
too big, resulting in an unnecessary vertical scrollbar.
So instead we wait 250ms and call do_getscroll after. This apparently
gives enough time for the menubar to render and for the DOM to take it into
account when feeding us the window dimensions. But if that race can be fixed
or worked around, we can change the behavior here to call first then wait
second.Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/114External tests2017-08-22T21:14:53ZGhost UserExternal testsBig merge just to get external tests working.
* fixed loader to use namespace prefixes for aliases
* removed hexloader and made a simple "hexmunger" branch of sys_do_load_lib for creators with non-alphanumeric characters in them
* chang...Big merge just to get external tests working.
* fixed loader to use namespace prefixes for aliases
* removed hexloader and made a simple "hexmunger" branch of sys_do_load_lib for creators with non-alphanumeric characters in them
* change all files that depended on "hexloader" library to instead use the simplified "hexmunger" interface
* force all objects to instantiate with no arguments. (Some libraries still need to be addressed, like iemtab)
* fixed some obvious namespace pollution caused by external devs leaving off the `static` keyword in their function declarations
* fixes lots of buffer overflows and invalid reads
* fix class_new to accept absolute path names without arbitrary 128 character symbol limit
* add methods to `[pdinfo]` that ease testing
* add an external tests patch and run it as part of the CI build
* clamp build to return a minimum number of successful object creations in the tests, or fail the build
* fixed various buffer overflows and invalid reads of external libraries (and that's just in the *constructors*, who knows what happens when the user actually sends messages to these things)
* ported tof/imagebang since it wouldn't create without args
* run tests on the Ubuntu CI runners with valgrind to catch memory errors. (One strange one still outstanding.) Eventually we should be able to have valgrind send an error exit code on memory errors and actually fail the build, once we have it running on the Debian runners (and possibly OSX runner), too.
* fix up various parts of the build system that were causing trouble
* fix various things in lyonpotpourri, and use a gitlab mirror until we can upstream the fixes
* make `[declare -lib]` handle absolute paths correctly (solves part of a problem with recursive new_anything calls getting generating when loading certain libs)
* fix some long-standing weirdness in iem libraries where objects needed to be loaded in a certain order for some symbols (that weren't declared `static`!) to get found.
* fix various mismatched or improperly formatted constructor args in various libsJonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/110WIP: External tests2017-08-22T21:14:54ZJonathan WilkesWIP: External testsSome API changes and (upcoming) patches to automate the testing of Pd-l2ork externals.
"External tests" might be a bit of a misnomer as the tools should be usable for testing internal classes as well.
Ideally, the tests would do the f...Some API changes and (upcoming) patches to automate the testing of Pd-l2ork externals.
"External tests" might be a bit of a misnomer as the tools should be usable for testing internal classes as well.
Ideally, the tests would do the following:
1. load all libs in the relevant libdir
2. fetch the list of new creator names that came from loading the libraries in the libdir
3. try to create an object using each new creator name (with required args if necessary-- unfortunately some externals fail)
4. for each successfully instantiated object, enumerate the methods and call each one with whatever args are required.
5. check the output against the output we saved from the previous release (of course this implies saving changed state in each release as necessary)
6. for each dsp method, output a single block of audio using `[switch~]` (probably want to check against known good state, too, but that may create a lot of state)
7. report any new method and new creators
The nice thing is that we can use a nonzero arg to "menuquit" in order to signal to CI that there was a failure in any of these steps.
This will allow us to more easily make changes to the codebase. Not only external libraries but also the build system and core, as any soft failures (of which there are many in the build system) that screw up something in an external lib will (eventually) trigger a hard failure in this test framework.
Difficulties
1. State-saving and other side-effect-based methods. For now we might have to exclude certain methods like "write" or "read" that are more difficult to test using such an automated framework.
2. "helper" creators and methods. Some objects have "proxy" objects with their own class names. However, I *think* such objects have their constructors disabled. It may be possible to add a check for that in `[classinfo]` and thus skip these. (Not sure what to do about "helper" methods, though.
3. Probably lots of other problems I'm not thinking of yet...https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/118use valgrind for the tests on all the linux runners2017-08-27T20:14:08ZJonathan Wilkesuse valgrind for the tests on all the linux runnersRun pd-l2ork under valgrind to find memory errors on all the linux runners.Run pd-l2ork under valgrind to find memory errors on all the linux runners.Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/117fix #365: iemguis freeze due to ggee/image data arriving before window exists2017-08-27T20:14:10ZJonathan Wilkesfix #365: iemguis freeze due to ggee/image data arriving before window existsThis is another stop-gap due to the GUI interface not protecting against
messages that arrive before the GUI windows has finished loading.This is another stop-gap due to the GUI interface not protecting against
messages that arrive before the GUI windows has finished loading.Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/116Fix dollararg parser2017-08-27T20:14:10ZJonathan WilkesFix dollararg parserThe valgrind tests on 64-bit ubuntu revealed a problem in binbuf_eval due to "$@" checks doing some inadvertent type punning on the t_word for A_DOLLAR. Whether this actually can cause a crash on any system I'm not sure, but this fix rem...The valgrind tests on 64-bit ubuntu revealed a problem in binbuf_eval due to "$@" checks doing some inadvertent type punning on the t_word for A_DOLLAR. Whether this actually can cause a crash on any system I'm not sure, but this fix removes the reliance on undefined behavior.Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/115fix #344: display glitch with preset_node2017-08-27T20:14:12ZJonathan Wilkesfix #344: display glitch with preset_nodeThis fixes a display bug that happens with any object connected to the outlet of preset_node.
Ideally Pd wouldn't send an update at all for the wire that feeds back into the inlet of preset_node. That wire exists on the patch but never ...This fixes a display bug that happens with any object connected to the outlet of preset_node.
Ideally Pd wouldn't send an update at all for the wire that feeds back into the inlet of preset_node. That wire exists on the patch but never gets drawn by the GUI. For now, we just check for existence to filter out the bug.Jonathan WilkesJonathan Wilkes