Pd-dev January 2023

pd-dev@lists.iem.at

16 participants
18 discussions

Re: [PD-dev] [clone] with subpatches (was Re: multichannel signals, preliminary support)
by Sebastian Shader 19 Jan '23

19 Jan '23

+1 Often there is a need to replicate a [pd ] object with arguments, that is specific to the parent's use/implementation. Patch-local 'embedded' abstractions have been mentioned as the way to achieve that in a consistent way too. I'm not sure the 'window' dialog thing is necessary in vanilla though. Generally it's the responsibility of the author to remove any other unused objects and I'm not sure why [ab ] should be different. 2 cents on [output~]: I also agree that some kind of standardized output-volume-slider abstraction should be offered, whatever it may be.. everything else in the help files can generally be copy/pasted into actual patches and used, and it's reasonable to have a simple abstraction for help files, it's almost always desirable to have some kind of volume control before [dac~] and for authors who want to use an output limiter or something they can just not use it.. seems at least as useful as the other abstractions in /extra. >> The main thing I was thinking about was (3) - because beginners are always>> copying patches out of the doc/... examples and then wondering why >> "output~" doesn't appear. If output~ were encapsulated in the patch itself >> that would save a lot of newbies a headache or two. >> > >Well, the thing is that now [output~] is an abstraction in 'extra', so Pd >should find it now :) > >But I think I see what you mean, and maybe Purr Data has implemented >something similar. They have this [ab] object. For reference: "*The [ab] >object is accompanied by a number of supplemental objects (abinfo, abdefs, >abclone) which let you inspect and clone private abstractions. There?s also >an ?Abstractions? dialog which can be accessed via the Window menu. This >will give you a quick overview of the private abstractions contained in a >patch. Also, it will show you private abstractions which aren?t currently >being used (i.e., don?t have any instances), so that you can select and >then delete them if they aren?t needed any more*." (from >https://agraef.github.io/purr-data-intro/Purr-Data-Intro.pdf ) > >This "private abstraction" is then a subpatch that is saved with the patch >file. It can have arguments and they have their own "$0". There's [abclone] >that can clone them too... > >I like this idea as I have a few external objects that are abstractions >which use [clone] and I need yet another abstraction to call inside clone. >This would make things much simpler as many times you don't really want to >create and clone a "real abstraction" (one you'd have for >different purposes other than using in a particular [clone] object in your >patch). > >cheers > >

1 0

send vector length and sample rate to "DSP" methods?
by Miller Puckette 19 Jan '23

19 Jan '23

On another topic, I'm finding that if you make a multichannel ~ object with no connections, it has no way to find the vector length which it needs in order to create its outputs. A multichannel object is (currently) required to create signals for all its outputs (because Pd can't predict how many channels are desired), but when there's no connection it then has to go back and ask the canvas (which it has to have earlier stored a private pointer to) for the "length". This is also rather bad because the canva then has to go searching for any block~ object it might contain. In short it's a mess. What if the dsp() routines were called this way: static void plus_dsp(t_plus *x, t_signal **sp, int length, float samplerate) ... in place of the current: static void plus_dsp(t_plus *x, t_signal **sp) I can't think of a downside to just adding the extra arguments; I think existing "dsp" methods with the old declaration will work fine if Pd calls them with the extra arguments. Does anyone see a problem with this? (or does anyone have a better suggestion)? cheers Miller

1 0

Re: [PD-dev] multichannel signals, preliminary support
by Dan Wilcox 18 Jan '23

18 Jan '23

I'm fine with objects like [osc~] not being multichannel is there is an easy way to parallelize / multiplex instances ... ie. clone. For consistency, one might want the Max approach of providing alternate versions of *all* dip objects, but if that's too much code overhead and we can concentrate this into clone or a similar object, it makes sense to me. >> Incidentally, now I think the word "distribute" is ambiguous - does anyone >> have a better word for packing/unpacking on way in and out of clones? >> > > fan-in/fan-out? ('fi', 'fo') I also thought of "fan in" and "fan out" ... probably to the consternation of IOhannes who added the "triggerize" feature. ;) -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 1

Re: [PD-dev] multichannel signals, preliminary support
by Jean-Yves Gratius 17 Jan '23

17 Jan '23

> Message: 4 > Date: Tue, 17 Jan 2023 08:32:35 +0100 > From: IOhannes m zmoelnig<zmoelnig(a)iem.at> > - [pack~] and [unpack~] are of course natural names for these objects. > *unfortunately* i have added objects of the same name (but with > different functionality) to zexy about 23 years ago. (the objects > predate zexy's use of*any* VCS; but the copyright boilerplate says > 2000/09/01 and i have no reason to distrust it). > so i expect that either old patches that use zexy's [pack~]/[unpack~] > are going to break, or the new multichannel [pack~]/[unpack~] won't be > usable if zexy is loaded as a multi-object library. VCV Rack uses [split] and [merge] for this kind of objects

5 23

Re: [PD-dev] Send~ and receive does not allow you to change name with a symbol!
by Dan Wilcox 17 Jan '23

17 Jan '23

I was thinking the same. Also, if the concern is "too many dsp objects", put them in sub patches / abstractions and use [switch~] to turn them off. This is what I do in our spatialization server patches at work where there are 4 levels of channel routing between 64 objects on each level. For instance, if there are only 4 outputs, all the other outputs are "switched off." > On Jan 17, 2023, at 8:47 PM, pd-dev-request(a)lists.iem.at wrote: > > Message: 3 > Date: Tue, 17 Jan 2023 16:47:27 -0300 > From: Alexandre Torres Porres <porres(a)gmail.com <mailto:porres@gmail.com>> > To: Christof Ressi <info(a)christofressi.com <mailto:info@christofressi.com>> > Cc: pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>, msp(a)ucsd.edu <mailto:msp@ucsd.edu> > Subject: Re: [PD-dev] Send~ and receive does not allow you to change > name with a symbol! > Message-ID: > <CAEAsFmgfeWnJTG4o4k6mrpK-S=waz+3n4OK8c9WvypZXMS6onA(a)mail.gmail.com <mailto:CAEAsFmgfeWnJTG4o4k6mrpK-S=waz+3n4OK8c9WvypZXMS6onA@mail.gmail.com>> > Content-Type: text/plain; charset="utf-8" > > so, [throw~] can set the destination, why not use it? -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

rpole~ / cpole~ infs and nans
by Matt Barber 17 Jan '23

17 Jan '23

Hello, Should I be getting infs and nans in rpole~ and cpole~ (0.53-1, Mac M1)? Does this mean PD_BIGORSMALL() is not working correctly? [image: image.png]

2 1

Re: [PD-dev] [leapmotion] 2.3.1 linking failure on Windows
by Christof Ressi 05 Jan '23

05 Jan '23

Thanks! I would say, distribute everything /except kernel32.dll/ (this one is always present on Windows) ucrtbase(d).dll (Universal C Runtime) is always present on Windows 10, but not necessarily on older Windows versions. BTW, ucrtbased.dll is the debug version of ucrtbase.dll (without 'd'). Alternatively, you might also try to link statically with the /MT option: https://learn.microsoft.com/en-us/cpp/build/reference/md-mt-ld-use-run-time… Christof On 05.01.2023 21:31, William Brent wrote: > Thanks for all the tips Christof, here's a Dropbox link to a .zip of > the external: > https://www.dropbox.com/s/v45itm3lrwsxaax/leapmotion.zip?dl=0 > > > On Thu, Jan 5, 2023 at 10:21 AM Christof Ressi > <info(a)christofressi.com> wrote: > > > so...just one last question (hopefully): what's the best > practice for > > packaging an external like this? The dependencies are: > > kernel32.dll is always present and must not be distributed. > > msvcp140d.dll, ucrtbase.dll and vcruntime140*.dll are Microsoft C > runtime libraries. > > Can you send me the binaries, so I can quickly have a look myself? > > > Would a .bat script be a good idea so that all of these could be > > copied to Windows/System32? > > Anything, but not this! The days of copying stuff into System32 are - > fortunately - long gone :-) > > Christof > > > > > _______________________________________________ > Pd-dev mailing list > Pd-dev(a)lists.iem.at > https://lists.puredata.info/listinfo/pd-dev > > > > -- > William Brent > > “Great minds flock together” > Conflations: conversational idiom for the 21st century > > www.conflations.com <http://www.conflations.com>

2 1

[leapmotion] 2.3.1 linking failure on Windows
by William Brent 05 Jan '23

05 Jan '23

Hello all, I'm finishing up work on new [leapmotion] and [ultraleap] externals and trying to make them available for all compatible platforms (I'll skip the rundown of which hardware and SDKs work on which platforms here unless it's helpful). I've got everything working except the [leapmotion] external for Windows. I'm using pd-lib-builder and MSYS2 MinGW 64-bit and am able to compile successfully, but linking to the 64-bit Leap library fails with a stream of "undefined reference to" messages. I'm positive that gcc can find the Leap.h header and the Leap.lib/Leap.dll libraries in my Leap SDK 2.3.1 directory, and have done a nearly identical build process for the [ultraleap] using the LeapC SDK 5.7.2 where linking succeeds and everything works fine. I'd be very grateful if anyone could shed some light on what I'm doing wrong here. There's no need for any Leap hardware for building, you just need to clone my [leapmotion] repo here: https://github.com/wbrent/leapmotion and download Leap SDK version 2.3.1 for Windows here: https://developer.leapmotion.com/releases >From there it's just a matter of editing the Makefile to specify your Leap SDK directory location and attempting a "make" in MSYS2. I'm using Windows 10 Home, Pd 0.53-1 (amd64-32), and pd-lib-builder version 0.6.0. Below is a truncated version of what I get in my attempts. Any suggestions or further questions are welcome, thanks! William ++++ info: using Makefile.pdlibbuilder version 0.6.0 ++++ info: using Pd API C:\Program Files/Pd/src/m_pd.h ++++ info: making target all in lib leapmotion ++++ info: making src/leapmotion.o in lib leapmotion g++ -DPD -I "C:\Program Files/Pd/src" -DMSW -DNT -DPD_LONGINTTYPE=__int64 -fcheck-new -Iinclude -I/c/msys64/dev/LeapDeveloperKit_2.3.1+31549_win/LeapSDK/include -Wall -Wextra -Wshadow -Winline -Wstrict-aliasing -O3 -ffast-math -funroll-loops -fomit-frame-pointer -march=core2 -msse -msse2 -msse3 -mfpmath=sse -o src/leapmotion.o -c src/leapmotion.cpp . . . ++++ info: making src/Dispatcher.o in lib leapmotion g++ -DPD -I "C:\Program Files/Pd/src" -DMSW -DNT -DPD_LONGINTTYPE=__int64 -fcheck-new -Iinclude -I/c/msys64/dev/LeapDeveloperKit_2.3.1+31549_win/LeapSDK/include -Wall -Wextra -Wshadow -Winline -Wstrict-aliasing -O3 -ffast-math -funroll-loops -fomit-frame-pointer -march=core2 -msse -msse2 -msse3 -mfpmath=sse -o src/Dispatcher.o -c src/Dispatcher.cpp . . . ++++ info: making src/LeapMotionObj.o in lib leapmotion g++ -DPD -I "C:\Program Files/Pd/src" -DMSW -DNT -DPD_LONGINTTYPE=__int64 -fcheck-new -Iinclude -I/c/msys64/dev/LeapDeveloperKit_2.3.1+31549_win/LeapSDK/include -Wall -Wextra -Wshadow -Winline -Wstrict-aliasing -O3 -ffast-math -funroll-loops -fomit-frame-pointer -march=core2 -msse -msse2 -msse3 -mfpmath=sse -o src/LeapMotionObj.o -c src/LeapMotionObj.cpp . . . ++++ info: linking objects in leapmotion.dll for lib leapmotion g++ -static-libgcc -static-libstdc++ -shared -Wl,--enable-auto-import "C:\Program Files/Pd/bin/pd.dll" -L/c/msys64/dev/LeapDeveloperKit_2.3.1+31549_win/LeapSDK/lib/x64 -o leapmotion.dll src/leapmotion.o src/Dispatcher.o src/LeapMotionObj.o -lLeap C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: src/leapmotion.o:leapmotion.cpp:(.text+0x411): undefined reference to `Leap::Frame::timestamp() cons t' C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: src/leapmotion.o:leapmotion.cpp:(.text+0x45d): undefined reference to `Leap::Frame::Frame()' . . . C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: src/LeapMotionObj.o:LeapMotionObj.:(.text+0xf8): undefined reference to `Leap::Interface::~Interface ()' collect2.exe: error: ld returned 1 exit status make: *** [pd-lib-builder//Makefile.pdlibbuilder:885: leapmotion.dll] Error 1 -- William Brent “Great minds flock together” Conflations: conversational idiom for the 21st century www.conflations.com

3 11

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 January 2023