Pd-dev February 2018

pd-dev@lists.iem.at

14 participants
18 discussions

Fwd: external help, please
by Alexandre Torres Porres 22 Aug '19

22 Aug '19

Hi folks, I need help on an external. I wanna perform a task on an array of signal inputs. It's a multichannel object, and I define the number of channels with an argument. Here's just the core of it, as an object named "mtx~", where I map the input to the output. And this is what happens. [image: Imagem inline 1] So you see I get a weird mirrored output, instead of something like "1 2 3 4 5 6". The perform method in the code is just static t_int *mtx_perform(t_int *w){ t_mtx *x = (t_mtx *)(w[1]); int nblock = (int)(w[2]); t_float **in_vectors = x->x_in_vectors; t_float **out_vectors = x->x_out_vectors; t_int i; for(i = 0; i < x->x_ch; i++){ t_float *in = in_vectors[i]; t_float *out = out_vectors[i]; t_int n = nblock; while(n--) *out++ = *in++; } return (w + 3); } What am I doing wrong? How should this go? See attached the help test example and code. Thanks

11 26

About inlet DSP prolog.
by Nicolas Danet 05 Aug '18

05 Aug '18

Hi, < https://github.com/pure-data/pure-data/blob/master/src/g_io.c#L210 > x->x_fill = x->x_endbuf - (x->x_hop - prologphase * re_parentvecsize); < g.io.c / line 210 > IMHO it does not properly shift the buffer in case of overlap (i.g. [block~ 512 4]) if stopping/restarting the DSP. x->x_fill = prologphase ? x->x_endbuf - (x->x_hop - prologphase * re_parentvecsize) : x->x_endbuf; The change above might solve the problem. I'm not 100 % sure. I'm currently testing the fix on Spaghettis < https://github.com/Spaghettis/Spaghettis/compare/dev >.

2 2

deken: major revamp of the packaging format for externals
by IOhannes m zmölnig 27 Feb '18

27 Feb '18

hi all, TL;DR: i suggest a new deken fileformat to be ready for double-precision Pd (once it comes) and other future vagaries. it requires you to update the search plugin and (if you use them) the cmdline tools. (this is a (longish) discussion/draft/poll. it's implemented, but not deployed yet.) everybody loves deken. thanks joe for the ignition and chr13m for the original implementation. now, 3 years later, i would like to fix a few inconsistencies and make deken fit for the future. # backstory smaller issues and real problems we have been seeing with the current implementation are: - archive formats depend on platform - the package version cannot be parsed reliably - the architecture strings are not well-defined. leading to much confusion and as a consequence, some parts of the architecture string are simply ignored by the current deken-plugin. unrelated to deken, there has been some work done in pd-vanilla land to get native Win64 binaries to work (for deken this means: a new architecture). and there have been rumours, that we might get double-precision builds for Pd - adding a whole new can of worms with incompatible externals. now deken is not ready for double-precision externals. as things are, it will happily suggest to download a single-precision external to a double precision Pd and vice versa, making Pd fail to load the suggested-as-compatible externals (in the best case) or simply crash Pd (in the worst case). the latter triggered a review of the deken packaging format, with the main task to make deken ready for the future. the result i've come up with so far, is a new filename scheme for external packages, which allows us to git rid of the design problems of the old one while keeping the pool of existing deken packages (which have well known properties) - and still be able to use it from a user's POV. # suggestion for a new format ## internal structure the internal structure of a deken packages stays the same as it already is: a simple archive of a directory tree containing whatever things the packager thinkgs need to be packaged. ## file format however, all deken packages should uniformly use the zip-format (instead of requiring linux&osx systems to support both zip and tgz). ## filename format the only real changes affect the format of the *filename* - as the filename contains all the meta-information of a deken-package. so my suggestion is, that the filename must have the form: `<libraryname>[v<version>](<arch1>)(<arch2>).dek` Example: helloworld[1.0.0](Linux-i386-32)(Windows-i386-32)(Darwin-amd64-32).dek ### libraryname at the beginning of the filename comes the libraryname. it may contain any characters with the exception of square brackets (`[]`) and parentheses (`()`). ### version e.g. "[v3.14]" the version of a library comes after the libraryname and must be given in square brackets (`[]`). the actual version number must be prefixed with `v`. (using a prefix allows us to easyily extend the filename format to contain more meta-info if we ever have the need). the version string may contain any characters with the exception of square brackets (`[]`) and parentheses (`()`). NOTE: this is different from the current format (which used `-v<version>-`) ### architecture e.g. "(Darwin-ppc-32)(Darwin-i386-32)(Darwin-amd64-32)" to understand whether an external is compatible with the currently running system, Pd needs to know about the architectures contained in the deken package. the full architecture specification consists of a number (zero or more) of arch sepcifiers, each surrounded by parantheses (`()`). one of the arch specifiers may be "Source", indicating that the package contains the source code for the binaries. each (remaining) arch specifier consists of 3 elements, delimited by dash: the Operating System (OS), the machine (CPU) and the floatsize of the external (e.g. "Windows-i386-32"). each arch specifier may contain any character with the exception of square brackets (`[]`) and parentheses (`()`), and the dash (`-`) is reserved as delimiter (so it must not be used in the components) typical values for the OS are "Linux", "Darwin" (for OSX/macOS) and "Windows". typical values for CPU are - "i386" (for 32bit Intel or AMD processors; this is also used if you are running a 32bit OS on a processors capable to run 64bit code) - "amd64" (for 64bit processors made by AMD or Intel) - "arm" (for generic ARM) - "armv7" (for a more specific ARM processor) - "ppc" (PowerPC) the CPU field describes the *calling convention* rather than the actual hardware of the CPU (e.g. Win32 (and WoW64 for that matter) uses a 32bit calling convention, even if the actual CPU is an "x86-64 CPU", so deken uses the arch-string "i386"). typical values for the floatsize are "32" (single precision float point). once there are double-precision builds of Pd available, this can also have the value of "64". NOTE: this is similar to the original format, but now that last value has an explicit meaning. ### extension all deken packages must use the uniform filename extension ".dek". (no more ~-externals.zip~ or ~-externals.tgz~ for you). objectlists (which keep their format) must use the ".dek.txt" extension. NOTE: this is different from the original format # backward compatibility now, if the deken-server returned the new .dek packages for all queries, the deken-plugin will fail to download and extract these packages (as it doesn't know how to handle ".dek" files, just like many major OSs). the proposal for this dilemma is: - the deken-plugin tells the server whether it is a "new" plugin (by means of setting the HTTP User-Agent field) - the deken-server will only return .dek packages if the plugin is new enough - the deken-server will automatically suggest to install the "deken" package if the plugin is too old. # implementation implementation is complete (afaict), but not yet deployed so far, i've implemented support for this in the [dek] branch of the deken repository. the (new) "deken" cmdline tool will (by default) create packages in the new format. (it can be tricked into creating legacy packages using the "--dekformat 0" flag). the (new) "deken-plugin" (aka "Find externals...") will happily work with both old and new formats. since the deken-plugin sends its query to a webserver (deken.puredata.info), this webserver (aka: the glue) must be updated as well (as it pre-parses all the available deken packages to be able to quickly answer any queries). code can be found at https://git.iem.at/zmoelnig/deken-server # discussion for now i see two points that might require discussion. 1) katja suggested to use the arch-specific Pd-extensions (e.g. "d_ppc") instead of the more verbose "Darwin-ppc"). personally i'm not totally opposed, but i kind of like the verbose naming, as it allows for more future possibilities. e.g. "b_amd64" currently means "FreeBSD-amd64" but what about other BSD flavours, are they compatible? (not that i believe that most OSs apart from the current three will matter very much to the community in the near future; but then i'd rather be too inclusive than not) 2) the proposed user-agent string might be considered a privacy issue. it currently is something like: "Deken/0.2.6 (Linux-amd64-32) Pd/0.48.1 Tcl/8.6.8" thus showing the Deken version, the Pd version the Tcl/Tk version and the architecture. note, that the current plugin uses Tcl/Tks default user-agent header, which already reveals the Tcl-version (and probably the OS, because different Tcl implementations seem to set the string differently). also, an architecture identifier is practically sent whenever your ordinary webbrowser sends a request to ...google or whatever. so i don't think that the header reveals problematic information, but then i thought it might be better to raise the awareness of others (you) first, before there are any complaints afterwards. 3) having the server add an automatic search for "deken" if you are using an outdated version. the idea is, that if people who are using a plugin which cannot handle the new .dek file, they are nagged into upgrading deken. the only way the server can communicate to the plugin is via the search results. so why not add a search-result for a newer (compatible) version of deken whenever the user might need it (because they are missing search results which require a newer plugin). however, such "slight nags" can be pretty^Wvery annoying. i'd like to have feedback on this before i enable it. that's probably it. fgmdasr IOhannes [dek] https://github.com/pure-data/deken/tree/dek

4 6

comment encoding
by Dan Wilcox 25 Feb '18

25 Feb '18

Something that's bothered me for a while is that numbers in comments are treated as actual numbers and not as pure text when saved/loaded, ie. a version number in a comment like: - 1.0: first working version strips the "1.0" to "1" when loaded: - 1: first working version I would think that the atom string saved/loaded for the comment object would simply represent text without needing much stripping/replacement. Relatedly, I also would think having an escape for endlines would be possible in the atom string. The comment object can clearly support displaying endless as you can add them fine, they just don't survive after saving. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

Re: [PD-dev] [PD] Fwd: external help, please
by Dan Wilcox 25 Feb '18

25 Feb '18

On newer macs, use lldb. > On Feb 25, 2018, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > #3 gdb > your code crashes? or does something bonkers? gdb to the rescue! > gdb can be a tricky beast, and there is much to learn, but even if you > only use the "backtrace" feature, you get at least an idea which line > causes the crash (which can help tremendously). > two things to keep in mind: > a) you must compile the code to be debugged with "-g", so the debugging > symbols don't get stripped away. > for whatever reasons, the pd-lib-builder Makefile doesn't set this by > default (most likely size- or speed-constraints; there was some > discussion, i don't remember the details), unless you build with "make > alldebug" > b) you should run Pd with "-nrt" inside the debugger, unless you want a > stream of "watchdog: signaling Pd" message to garble all your output.

1 0

Array bug and inconsistency
by Pierre Guillot 23 Feb '18

23 Feb '18

Hi, The documentation 16.more.array.pd looks a bit deprecated so I suggested a small update: https://github.com/pure-data/pure-data/pull/309 Anyway, I think I found a bug: renaming an array doesn't rename it graphically (you have to update the patch window in a way or another). And I have two questions/suggestions: - The message "bounds" should also resize the array (perhaps?) - Using a list to change the elements of an array should also resize the array if needed (or at least notifying if the elements are out of bounds?). Cheers, Pierre

1 0

Bug when saving the patch with Pd 0.48-1
by Pierre Guillot 23 Feb '18

23 Feb '18

Hi, I don't know if anybody already encountered this bug. If the focus is on the window of an array object (displayed by clicking on the object) and you save the patch (via the menu or via cmd+s), the patch closes instantly after. On MacOS 10.13.3 with Pd 0.48-1 - Tk 8.6.6 and Tk 8.5.19 PS: The problem doesn't occur with the text object so I guess it could be solved. PPS: I'll create a PR on Github but I prefer to be sure that's not a known problem that I missed. Cheers, Pierre

4 5

Array - how to get the drawing mode
by Pierre Guillot 23 Feb '18

23 Feb '18

In Pd you can change the drawing mode of an array: - polygon - points - bezier curve I'd like to know if there is a way in C to find which mode is used. I can't find anything in the _glist structure nor in the _garray. Thanks, Pierre

2 2

osx -stdlib path
by Alex 21 Feb '18

21 Feb '18

I have an external I've created that I've put into: /Users/alex/Documents/Pd/externals/jit_expr/ the binary is called "jit_expr.pd_darwin" xnor-work:~/projects/perfect/center$ ls /Users/alex/Documents/Pd/externals/jit_expr/ LICENSE-parser LICENSE-pd LICENSE-xnor jit_expr-help.pd jit_expr.pd_darwin In the binary, the externals themselves are named "jit/expr" "jit/expr~" and "jit/fexpr~" On my work, osX machine, when I [declare -stdlib jit_expr] I then fail to create [jit/expr] On my home, linux machine, where my external folder is located at /home/alex/.local/lib/pd/externals/jit_expr and appropriately named jit_expr.pd_linux I succeed to create [jit/expr] after [declare -stdlib jit_expr] Is this a bug am I not following some naming convention that I should be? I could see wanting to put my external in a folder called "jit" and then naming them "expr", "expr~" etc but I could imagine "jit" is more likely to collide and so "jit_expr" seemed more reasonable. maybe I should just call the whole thing "jit_expr", and just call the objects "expr" etc without the prefix in the code and then be able to create [jit_expr/expr] with no declare because it'll be in the stdlib already? Am I confusing conventions that exist for single binary libraries with multiple objects and binaries with only one? Either way, should I file a bug that the behavior isn't the same on osx and linux? thanks, Alex

3 7

cross-compiling linus-to-windows 64 bit using automake
by Miller Puckette 21 Feb '18

21 Feb '18

I'm able to sucessfuilly cross-compile 64-bit windows targets from linux now, albeit a bit shakily. Here's what I've found so far: 'libtool' has a library dependency, -lmsvcrt , which breaks compilation. It works just to delete it. Somehow a 32-bit version of libwinpthread-1.dll gets installed - I have to manually replace it with a 64-bit one. and... try as I might I still can't get it working with tcl/tk 8.6 - I have to yse 8.5. More on that later. My compilation steps currently look like this (after making a clean directory to put it in, /home/msp/bis/work/pd-versions/build-dirs/test85): v=0.48-1test3-ia64 tkversion=8.5.19 s=/home/msp/tmp/clean-pd-source git clone ~/pd $s cd $s ./autogen.sh cd /home/msp/bis/work/pd-versions/build-dirs/test85 $s/configure --host=x86_64-w64-mingw32 CPPFLAGS='-DPD_LONGINTTYPE=__int64' sed -i '/-lmsvcrt/s/-lmsvcrt//g' libtool make cd msw cp -a /home/msp/bis/work/pd-versions/build-tk-on-win64/msw/tcltk-$tkversion . /home/msp/bis/work/pd-versions/build-tk-on-win64/msw/msw-app.sh \ --builddir .. --tk tcltk-$tkversion $v cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libwinpthread-1.dll \ pd-$v/bin/ (note: I make the clone of the Pd source so I don't have to run automake in my 'clean' source tree). When I try this for 8.6.8 I change the configuration line as follws: $s/configure --host=x86_64-w64-mingw32 \ --with-wish=wish86.exe \ CPPFLAGS='-DPD_LONGINTTYPE=__int64 -DWISH=\"wish86.exe\"' It all builds fine and I'm able to run wish86.exe all right; but when I try to test it as in: wine pd-0.48-1test2-ia64/bin/wish86.exe `pwd`/pd-0.48-1test2-ia64/tcl/pd-gui.tcl I get signs of memory corruption that I haven't been able to track down (my debugging statements in pd-gui.tcl generate binary garbage). This seems to be an interaction between wine and tcl/tk and is almost certainly too deep for me to figure out. This doesn't seem to be a fatal problem though - if my "test" 64-bit build works OK I can live with that for at least until 8.7 comes out (and who knows what problems that might fix and/or introduce) cheers Miller

3 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev February 2018