purr-data issueshttps://git.purrdata.net/jwilkes/purr-data/-/issues2018-12-19T23:24:06Zhttps://git.purrdata.net/jwilkes/purr-data/-/issues/491make light2018-12-19T23:24:06ZJonathan Wilkesmake lightfor make light it appears all we need on a debian system are `autoconf` and `rsync`
Also needed for the nw.js gui is libgconf-2-4
Update the docs to make this clear.for make light it appears all we need on a debian system are `autoconf` and `rsync`
Also needed for the nw.js gui is libgconf-2-4
Update the docs to make this clear.Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/issues/494toplevel makefile light-double recipe broken on OSX2018-12-27T03:01:35ZJonathan Wilkestoplevel makefile light-double recipe broken on OSXIt appears that `make light-double` on OSX produces a binary with PD_FLOATSIZE set to 32.
It should set PD_FLOATSIZE to 64.
Haven't checked the other platforms yet.It appears that `make light-double` on OSX produces a binary with PD_FLOATSIZE set to 32.
It should set PD_FLOATSIZE to 64.
Haven't checked the other platforms yet.Albert GräfAlbert Gräfhttps://git.purrdata.net/jwilkes/purr-data/-/issues/495new build warning in GCC 8 due to -Wcast-function-type2018-12-30T23:36:57ZJonathan Wilkesnew build warning in GCC 8 due to -Wcast-function-typeGCC 8 adds this noisy warning: `warning: cast between incompatible function types from` etc.
This is happening for the t_newmethod cast in `*_setup` functions.GCC 8 adds this noisy warning: `warning: cast between incompatible function types from` etc.
This is happening for the t_newmethod cast in `*_setup` functions.https://git.purrdata.net/jwilkes/purr-data/-/issues/496fix z-ordering on unaccelerated redraws2019-01-06T23:34:16ZJonathan Wilkesfix z-ordering on unaccelerated redrawsSome objects-- especially externals-- will do redraws by having two gobj_vis calls in a row to revis the object.
This on its own will put the redrawn object at the top of the z-order stack.
We should probably revisit these "unaccelerat...Some objects-- especially externals-- will do redraws by having two gobj_vis calls in a row to revis the object.
This on its own will put the redrawn object at the top of the z-order stack.
We should probably revisit these "unaccelerated redraws" and add a call there to re-order the newly drawn object in its proper z-order.
I think there are already some functions to do this which are currently used by the undo system. We just need to utilize them.Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/issues/499add transform method to drawarray2019-01-15T04:11:55ZJonathan Wilkesadd transform method to drawarrayDoesn't seem like there's any reason to prohibit this. Must have originally used a nested <svg> instead of <g>Doesn't seem like there's any reason to prohibit this. Must have originally used a nested <svg> instead of <g>Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/issues/432GOP borders2019-01-24T03:33:11ZJoão PaisGOP bordersjust saw now that gop borders can be dragged and resized manually. Very nice touch. Some suggestions:
- border resizing for vertical/horizontal dimensions (not just all at once)
- double-clicking the red square the settings window open...just saw now that gop borders can be dragged and resized manually. Very nice touch. Some suggestions:
- border resizing for vertical/horizontal dimensions (not just all at once)
- double-clicking the red square the settings window opens up.
- select the border, and move it with the arrows or shift+arrow keys (as a normal object)
- or a "select all + nodes" option, where the whole patch + gop box can be draggedhttps://git.purrdata.net/jwilkes/purr-data/-/issues/459text box display2019-01-27T02:54:40ZJoão Paistext box displayHere are some bugs in text boxes;
��������- when editing the patch, the text box takes up more vertical space than the visible text. This "invisible box" increases with the number of lines. This was a problem in pd-ext, but has been cor...Here are some bugs in text boxes;
��������- when editing the patch, the text box takes up more vertical space than the visible text. This "invisible box" increases with the number of lines. This was a problem in pd-ext, but has been corrected in pd-van;
������- if the font is set to 12 (or a multiple), when editing the display of the text shifts a couple of pixels higher;
���- when opening this patch in pd-van, there are many weird symbols after a semicolon. Correcting the patch in pd-van solves the problem (I copy-pasted the text in here, so you can see them at the start of each line);
��- the font display (and line height?) in pd-van is smaller than in purr
See attached file as well.
[text_comments.pd](/uploads/aada7125192e4b8ecb4f288929715e55/text_comments.pd)https://git.purrdata.net/jwilkes/purr-data/-/issues/504attempt to upgrade OSX runner and use valgrind with it2019-01-31T02:28:08ZJonathan Wilkesattempt to upgrade OSX runner and use valgrind with itGo ahead and try to upgrade OSX runner to mojave.
If it works, try making valgrind a requirement in the CI instructions. Then track down any memory errors that valgrind catches.Go ahead and try to upgrade OSX runner to mojave.
If it works, try making valgrind a requirement in the CI instructions. Then track down any memory errors that valgrind catches.https://git.purrdata.net/jwilkes/purr-data/-/issues/506make comment text selectable in run mode2019-02-13T16:10:24ZJonathan Wilkesmake comment text selectable in run modeBecause... why not?Because... why not?Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/issues/507wireless object navigation2019-02-13T19:52:44ZJonathan Wilkeswireless object navigationGo ahead and implement this:
https://git.purrdata.net/jwilkes/summer-of-code-ideas-list#navigation-of-wireless-objects
It's currently in the GSoC list but should be removed because it's too easy a project:
1. Add a global pd receiver ...Go ahead and implement this:
https://git.purrdata.net/jwilkes/summer-of-code-ideas-list#navigation-of-wireless-objects
It's currently in the GSoC list but should be removed because it's too easy a project:
1. Add a global pd receiver named something like "debug_symbol $symbol $classname"
2. Add to m_pd.c: `bindlist_print(t_symbol *s, t_symbol *classname);`
3. Have bindlist_print send to the GUI an array of gui_x(pd) which are part of the s->s_thing bindlist that match the classname given. If there's only one pd behind the s_thing that matches then send it as an array with a single element. If there's nothing then send an empty array. If there's no classname argument given, just spit out all the elements of the bindlist.
4. In the GUI, receive the array and print to console a) the classname and binding symbol, b) the length of the array, c) each matching object, hyperlinked like pd_error does so that the user can click and navigate to the object. Could even make a little slider widget to scrub among them, or possibly a toggled hyperlink where you can mouse over a series of "1 2 3 4 5" links to highlight each object.
5. For send/receive/catch/etc., hyperlink the first argument in the GUI so that clicking it calls "debug_symbol $symbol $classname"
That should pretty much do it.Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/issues/508port savestate class from Pd Vanilla2019-02-16T02:34:16ZJonathan Wilkesport savestate class from Pd Vanilla3.0.0Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/issues/17can't undo connection in some circumstances2019-02-25T08:20:34ZJonathan Wilkescan't undo connection in some circumstancesConsider:
```
[pd foo] <- put an [outlet] inside the subpatch
|
[print]
```
1. Go inside [pd foo] and clear the [outlet]
2. In the [pd foo] window, click "Undo" in the menu
Bug! Notice that the connection between [pd foo]---...Consider:
```
[pd foo] <- put an [outlet] inside the subpatch
|
[print]
```
1. Go inside [pd foo] and clear the [outlet]
2. In the [pd foo] window, click "Undo" in the menu
Bug! Notice that the connection between [pd foo]---[print] does not get recreated.Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/issues/493autotune~ uses float instead of t_sample2019-03-03T17:11:09ZJonathan Wilkesautotune~ uses float instead of t_sampleLooks like `[autotune~]` hard-coded `float` in some places instead of `t_sample`.
Fix this and test to make sure the algo itself doesn't depend on any single-precision float bitmath or anything else like that.Looks like `[autotune~]` hard-coded `float` in some places instead of `t_sample`.
Fix this and test to make sure the algo itself doesn't depend on any single-precision float bitmath or anything else like that.https://git.purrdata.net/jwilkes/purr-data/-/issues/397s_stuff.h.in is bad2019-03-04T15:26:40ZJonathan Wilkess_stuff.h.in is bad`PD_BUILD_VERSION` needs to be moved from s_stuff.h.in into its own file like s_version.h.in or something.
The problem is that there is a *lot* of other functionality inside s_stuff.h, and a developer (like me) is very likely to just go...`PD_BUILD_VERSION` needs to be moved from s_stuff.h.in into its own file like s_version.h.in or something.
The problem is that there is a *lot* of other functionality inside s_stuff.h, and a developer (like me) is very likely to just go to town on s_stuff.h forgetting that it's generated by s_stuff.h.in.
Then when doing `git status` the changes to s_stuff.h aren't listed in the "Changes not staged for commit." That's because s_stuff.h isn't tracked-- it's auto-generated. That makes it extremely easy to commit, completely forgetting about one's changes to s_stuff.h and consequently losing data.
Alternatively, if you just do `git add .` you'd end up tracking the autogenerated s_stuff.h file and then get confused when those changes end up getting overwritten in the CI by s_stuff.h.in.
Either way, it's way better to cordon off the auto-generated version number into its own header that nobody is ever likely to touch.Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/issues/515Feature request: collapse / create subpatch2019-03-05T02:47:09ZJens DreskeFeature request: collapse / create subpatchSooner or later everyone working on a patch has to clean up using subpatches. Sorting the spaghetti helps to read, maintain and extend the patch.
Doing this manually needs time and it’s risky to mess things up. It would be a great improv...Sooner or later everyone working on a patch has to clean up using subpatches. Sorting the spaghetti helps to read, maintain and extend the patch.
Doing this manually needs time and it’s risky to mess things up. It would be a great improvement if purrdata would assist on creating subpatches automatically. Select some objects, click collapse and get a sub patch with all necessary inlets and outlets connected automatically.
Also uncollapsing existing subpatches would be useful while cleaning up.
I have some interesting rather complex patches I don’t share- just because they look to messy. I guess other users also have a collection of these patches.
Perhaps this idea could be part of a gsoc project?https://git.purrdata.net/jwilkes/purr-data/-/issues/514Stack overflow crash with qlist2019-03-06T14:53:08ZmyQwilStack overflow crash with qlistThere appears to be a specific type of stack overflow scenario that pd-vanilla can handle but purr-data cannot. I wrote a tiny patch that basically just consists of a message that reads [next(, and a [qlist]. The message is connected to ...There appears to be a specific type of stack overflow scenario that pd-vanilla can handle but purr-data cannot. I wrote a tiny patch that basically just consists of a message that reads [next(, and a [qlist]. The message is connected to both the qlist's inlet and 2nd outlet. So clicking [next( is gonna create an infinite loop, but pd-vanilla will not crash in this scenario, whereas purr-data will, or at least on Windows, I haven't tried any other distro yet.
Also, here's the patch: [infinite-loop.pd](/uploads/fa145640db4f65d524700bb113825478/infinite-loop.pd)https://git.purrdata.net/jwilkes/purr-data/-/issues/516use sys_open and sys_fopen in all relevant places2019-03-08T05:02:34ZJonathan Wilkesuse sys_open and sys_fopen in all relevant placesWe need to do a pass through both the core (`pd/src`) and the externals (`externals`) and replaces syscalls to open and fopen with sys_open and sys_fopen, respectively. (Both are defined in `pd/src/s_path.c`.)
That will ensure the files...We need to do a pass through both the core (`pd/src`) and the externals (`externals`) and replaces syscalls to open and fopen with sys_open and sys_fopen, respectively. (Both are defined in `pd/src/s_path.c`.)
That will ensure the files are opened properly on Windows machines, and with filenames converted properly for non-ASCII characters.
Edit: we initally hooked these in for binbuf_read, but there are other places in the code where we need it.https://git.purrdata.net/jwilkes/purr-data/-/issues/520update pdlua help patch2019-03-19T03:19:11ZJonathan Wilkesupdate pdlua help patch[Here](https://git.purrdata.net/Konsumer/pd-lua/commit/23d4387be8c727f146acc29c476a7d2ad29157d1) is a revision for the pdlua help patch. It needs to be considered upstream in github, then I can pull for the Purr Data gitlab mirror.[Here](https://git.purrdata.net/Konsumer/pd-lua/commit/23d4387be8c727f146acc29c476a7d2ad29157d1) is a revision for the pdlua help patch. It needs to be considered upstream in github, then I can pull for the Purr Data gitlab mirror.Albert GräfAlbert Gräfhttps://git.purrdata.net/jwilkes/purr-data/-/issues/521fix background in dmg installer for osx2019-03-19T14:42:04ZJonathan Wilkesfix background in dmg installer for osxFor the OSX dmg installer, the background image isn't getting displayed in the little window where the user drags Purr Data's icon into the Applications folder.
The relevant background image is `purr-data/packages/darwin_app/background....For the OSX dmg installer, the background image isn't getting displayed in the little window where the user drags Purr Data's icon into the Applications folder.
The relevant background image is `purr-data/packages/darwin_app/background.png`
Might want to check both `purr-data/packages/darwin_app/Makefile` as well as the build output to see if there's an error somewhere.https://git.purrdata.net/jwilkes/purr-data/-/issues/518hex2dec2019-03-20T00:31:22Zkonsumerhex2decI am creating a sysex stream with `[ midiout ]` and it would be handy if `[ hex2dec ]` worked, so I could use the same hex strings as are found in the docs and scripts in other languages, without having to convert them all to decimal mys...I am creating a sysex stream with `[ midiout ]` and it would be handy if `[ hex2dec ]` worked, so I could use the same hex strings as are found in the docs and scripts in other languages, without having to convert them all to decimal myself.
When I looked at help for `[ hex2dec ]`, I see `doesn't seem to work`, and indeed when I try different things, it doesn't output what I would expect:
```
[f 100] => "symbol"
[ 100 ( => "symbol"
[ symbol 100 ] => "symbol"
[ list 100 100 ( => "symbol"
```
I expect all of these to output `256` (float).
I had a look at [the code](https://git.purrdata.net/jwilkes/purr-data/blob/master/externals/cxc/hex2dec.c), and it looks ok, at least from my cursory 5 minute perusal.
I've been meaning to get better with `pdlua`, so I implemented it this way, as it was quick & easy, and it illustrates my expectations. Is there interest in a PR? Can I do it in lua, or should it be in the original C code?
Here is my lua version:
[hex2dec.zip](/uploads/34e4bf2534b6a30294a59fe8b8c02e37/hex2dec.zip)
![Screenshot_2019-03-15_19-22-55](/uploads/23bc464a1a870196417d4ba2cd6aef18/Screenshot_2019-03-15_19-22-55.png)