Pd-list December 2015

pd-list@lists.iem.at

56 participants
94 discussions

Re: [PD] soundtouch~ for ARM (Raspberry Pi / RPi)
by haima 05 Apr '18

05 Apr '18

Thanks! Re: the "à": I cheated - copy and paste... hahah The soundtouch~.pd_linux file you compiled works great here on my Pi, thanks! Just out of interest, ofter modifying the Makefile to be correct for the ARM, what were the other steps required to compile it? I can't figure out what to do with a Makefile... Cheers! and +à :) > Message: 2 > Date: Wed, 20 May 2015 23:03:58 -0400 > From: puredata(a)11h11.com > To: pd-list(a)lists.iem.at > Subject: Re: [PD] soundtouch~ for ARM (Raspberry Pi / RPi) > Message-ID: > <20150520230358.Horde.k0FQZnmx7yRVXUsen0AmIbA(a)courrier.privatedns.com> > Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes > > Hi Haima, > > +1 for finding the "à" on your keyboard (or did you "cheat"), but it's > not my name or nick :) à+ means see "you later" in french. anyway > here's the download link again: > https://dl.dropboxusercontent.com/u/1455235/stuff/soundtouchrpi.zip > > Cheers~ > > >

6 5

Re: [PD] fft~ bug in Pd-0.46-7-64bit.app on OSX
by Robert Esler 31 Dec '17

31 Dec '17

As far as I know Pd stopped using the mayer fft library in .46, which is probably why this is new behavior. I only get what you’re experiencing with a block size of 8. Otherwise, it seems to perform as expected. To really understand if this is a bug or not is to know which fft library is being used for OS X. My guess is it’s the OOURA but it’s not clear from looking at [fft~] object code that comes with distribution. You could also download the old library and recompile Pd, but I doubt it’s worth it. -Rob ------- Hi list, There's either a major bug in the [fft~] objects in Pd-0.46.7 (64bit OSX) or I'm going crazy. I'd love to see if others can reproduce it. Basically, for [block~] sizes less than 32 bits, [fft~] doesn't perform -- it just passes the signal through unchanged. [ifft~] does the same. The [rfft~]-[rifft~] is a little more complicated -- it passes signal through but zeroes out the last N/2 for [block~] sizes less than 64. See the attached patch, which only shows [fft~]. The saved contents of the tables on opening are the results for [block~ 8] on my machine, for quarter-nyquist at 44100. I've never seen this before in other versions of Pd. Anyone else get this behavior? Matt

5 9

retrigger [tabread4~] sampler without clicks
by Federico Galland 17 Dec '17

17 Dec '17

Hi, I'm working on a granular sampler borrowing parts of the patch on pd-tutorial (http://www.pd-tutorial.com/english/ch03s07.html). Everything works smoothly except for one little annoying problem. If I fire the sample before the last one is through, sometimes I get a click at the beggining of the playback. This is happening on a percussive sound (rapid envelope attack) so I'm guessing it's got something to do with [tabread4~] failing to interpolate between whatever the last amplitude value was and the first wavetable value. This http://crca.ucsd.edu/~msp/techniques/latest/book-html/node63.html can probably be used to solve my problem, but I can't figure out how (or where in the patch) I should implement it. Any clues would be greatly appreciated. Thanks a lot, and have a good one. ps. I tried to comment the patch to make it understandable. It is still, however a work in progress. Let me know of any questions. -- Federico Galland <federicogalland(a)gmail.com>

5 4

[PD-announce] All-in-one 'websocket server + cross-browser multiplayer/multitouch demo' patch for Pd-extended
by Nicolas Lhommet 30 Nov '16

30 Nov '16

"websocket-server in a patch.pd" single pd patch file contains a reusable and fully documented websocket server, meant as an easy way to experiment with Pd<->web-browsers communications through websockets, without the need of other software or any external to compile A demo is included in the same patch : 'Flames', a simple cross-browser, multi-touch and multi-player graphical interface which makes Pd play creepy sounds :) and its javascript code for websockets is also documented. Just try it : open it with Pd-extended 0.43.4 on Windows, Mac or Linux, fire any recent web-browsers (on same machine or other computer, smartphone or tablet on same local network) with the URL provided in the main window, and you're good to go ! You can download the patch from these forums : http://puredata.hurleur.com/sujet-10062-websocket-server-patch-extended-dem… required to get the file) direct link to patch : http://puredata.hurleur.com/attachment.php?item=4945 Cheers, Nicolas Lhommet

4 8

For sample players based on [line~], [vline~], or [phasor~], how can we be sure all samples are being played?
by Reed Perkins 11 Jun '16

11 Jun '16

Hello all, [line~], [vline~], and [phasor~] are used to generate line ramps in basic sample-playback patches. The output of these objects is usually multiplied by the total number of samples in a sound file (that has already been loaded into an array or table) and fed into the input of something like [tabread4~]. In other words, we use these line-ramp objects to traverse the indices of a table where a sample is loaded at a given speed. My questions are these: 1. Do these line-ramps generate enough numbers such that every sample in a table will be read? 2. Does it matter if, say for example, [tabread4~] receives a decimal number for an index, like 333987.8, which can be caused by multiplying the output of [phasor~] (which goes from 0-1) by the total amount of samples (usually a much larger number). 3. Does the output of [line~] and [vline~] vary due to being asked to generate a ramp faster or slower? If I ask [line~] to go from 0-555987 in 3789 milliseconds, will the actual output be the same or different if I then ask [line~] to go from 0-9876545 in 40 milliseconds I realize this is totally theoretical, because in all honestly I wouldn't be able to hear a difference if samples are being skipped, but I want to know :) Thanks for your time.

7 14

route large number of voices
by Benoît Fortier 15 Apr '16

15 Apr '16

Hi, it seems common practice to use route to dispatch individual "notes" to different voices when building a polyphonic synth. But these days I'm working on a "synth" which is going to have a large number of voices (probably around 100) and I was wondering if there's a better way to route those voices other than use route with a hundred creation arguments. I though about sending every "note" information (including the voice number) to every voices and to put a test at the inlet of every voice abstraction to filter the incoming data so that only one voice actually plays the "note" but I was wondering if there was a better option, like dynamically set the destination of a send object... I did a few test but couldn't find an elegant solution by myself. Many thanks pd-list! Benoît Fortier 581 995-5622

5 6

[Bug]Dynamic Patching causes memory leak
by Zack Lee 23 Mar '16

23 Mar '16

Hi, I found out that dynamic patching causes memory leak or overloading the CPU usage. Which means, if you create and delete an object many times by dynamic patching, at some point, the CPU usage will be overloaded and you will hear the glitch in audio. I tried to find a way to fix this issue, but so far the only solution seem to be to close and re-open the patch. I have tested this with both pd-0.46-7 and pd-extended 0.43.4 on Mac OS X 10.10.3. I attached the test patch below so please check and see the problem I mentioned. The file name should be "test.pd", so please change the file name if it changes to a different name once you download it. -Zack

3 5

moog~ in pure pd?
by Dan Wilcox 18 Feb '16

18 Feb '16

Forgive me, I'm no low level dsp guru. I'm curious. How would one make the ggee [moog~] external in pure pd? [vcf~] sounds close, but of course, it's a band pass so it's not a real replacement. I messed with rjlib [e_beequad= + [u_lowpassq] which sounds pretty good, but there no signal rate frequency control, which I'd need for those nice filter sweeps. I'm trying to lessen my reliance on externals (where possible) and moog~ is one of those without an obvious replacement. -------- Dan Wilcox @danomatika danomatika.com robotcowboy.com

8 11

consolidate backward- and MaxMSP compatibility in Cyclone (was: Purpose of Cyclone)
by katja 18 Jan '16

18 Jan '16

Hello Alexandre, Fred Jan, pd list, It makes me sad to see your earlier productive collaboration on Cyclone stagnating with this dispute about the purpose. Between 2005 - 2015 the purpose of Cyclone has been determined more by what it was than by what it should be, by lack of human resources [1]. With the recent increased effort of testing, fixing and innovation there's an opportunity to redefine intentions and ambitions. Let's try to figure out a generic approach where backward compatibility doesn't conflict with MaxMSP compatibility and innovation, so anyone can contribute to the project according to their skill, interest and ambition. My proposal would be to sacrifice forward compatibility of older versions if needed. Classes which pose the compatibility dilemma may be made to operate in multiple modes. Sometimes this can be achieved by message, and when the number or type of inlets / outlets are concerned (like average~) it can be achieved with creation arguments. Now you have to decide which is the default behavior. With decades worth of Pd patches in mind it seems logical to keep the original Cyclone behavior as default and offer the MaxMSP compatible mode as an alternative. The help patch demonstrates how to use the newly developed mode. A class setup message can advertise it too. There's always this caveat with introducing new message selectors and creation arguments: old versions of the class don't support them so you could still end up with broken patches. But this is less problematic than backward incompatibility. The class help patch must give clear information about the version where new functionality was introduced, and anyone who applies it in a distributed Pd patch can inform the user about version requirements. No spurious malfunctions, but at worst a clear hint to upgrade. You may wonder what is my own involvement with Cyclone. At the moment, none apart from following the discussion. Earlier this year I spent a few months developing Makefile.pdlibbuilder as a generic build system for Pd libs. Replacing the indecipherable build system of Cyclone was the ultimate test case for this work, and it helped speed up Fred Jan's work on the library. I became aware how big a project it really is. It could use the love and care of more people besides Alexandre and Fred Jan. Katja [1]. Cyclone (part of miXed) was unfortunately abandoned by it's original author Krzysztof Czaja after 2005. The ambitions with this wonderful project were then in practice scaled down to fixing bugs in the alpha versions, as illustrated by the commit history of it's SVN repository http://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/miXed/cycl…. On Mon, Dec 21, 2015 at 6:26 PM, Alexandre Torres Porres <porres(a)gmail.com> wrote: > > 2015-12-15 16:22 GMT-02:00 Fred Jan Kraan <fjkraan(a)xs4all.nl>: >> >> Hi Alexandre, >>>> >>>> Compatibility is limited to a very old version of Max/MSP. >>> >>> >>> That really confused me, as a Max 7 user... >> >> >> Why? If any version of Max/MSP looks like Pd, it is 4.6 (or maybe earlier >> versions, but I don't have access to those...). > > > Because it is not a matter on how it "looks", and Max 7 is still the same > patching environment, it's not like it changed and lost compatibility, hence > I'm using both Max 7 and cyclone and I'm happy about it. > > It's not like Max 7 killed and broke backwards compatibilty with earlier > versions and patches. So we don't have to consider it as having to be tied > to 4.6.. > > Perhaps you mean we'll never be able to come close to what Max 7 is now in > general. But I don't think that was ever possible and the purpose of cyclone > was not to make a clone of the Max/MSP Software. > > I think this is a very serious and sensitive topic, as the purpose of > cyclone is not being really considered in your point of view, and this might > interferes with the purpose, or even kill it... > >>>> >>>> For me this makes backward compatibility more important >>>> than with an obsolete Max/MSP version. > > > If I got it right, you're basically saying: > > - Cyclone should be a copy of an outdated and obsolete Max/MSP version and > we shouldn't care on keeping up with improvements in Max because it is > impossible and only really likely or reasonably possible within the > limitations of max/msp 4.6 as a software. > > - Not caring about the developments in earlier versions of Max, we're stuck > to 4.6, but since it is an obsolete version of Max, we shouldn't care about > being faithful to it either, or Max for that matter. > > Thus, we'd basically lose the idea of having a library of objects compatible > to Max/Msp objects, and we also do not care of the original purpose of it. > Well, that is not a good take on my opinion. > > I agree Cyclone is now (and has always been because of its stage of > development) a copy/clone of an outdated and obsolete Max/MSP version. That > is why I think it's good we'd try to keep it up to date with and care on > keeping up with improvements in Max/Msp objects. > > >>> About [average~], the thing is that was wrong to begin with, it couldn't >>> load max patches in the first place, it should have been signal all >>> along. >> >> >> I agree average~ was wrong all along. But it has been wrong wrong for >> about twelve years. I do not want to invalidate twelve years of patches. >> If you want to copy a Max patch with average~ in Pd, you could use another >> object or an abstraction. PureData is supposed to be a tool to help >> understand DSP technique and make creative sounds. Not to be able to blindly >> copy Max/MSP patches. > > > Again... that WAS the purpose of Cyclone in Pd... to be able to implement > MAx/Msp objects in Pd - and that seems to be completely unregarded by your > development effort in Cyclone. > > Btw, let me post what the purpose of cyclone is still described as in here: > https://puredata.info/downloads/cyclone > > I'll bring some exerpts and highlight a few key words. > > Cyclone: a library of clones of Max/MSP 4.5 objects > > "a library of PureData classes, bringing some level of compatibility between > Max/MSP and Pd environments (...) In its current form, cyclone is mainly for > people using both Max and Pd, and thus wanting to develop cross-platform > patches. > Cyclone also comes handy, somewhat, in the task of importing Max/MSP 4.x > patches into Pd. Do not expect miracles, though, it is usually not an easy > task." > > The project description is outdated, see that importing max patches to Pd > was not a main goal then, and now we could basically forget about it - but > the main point still remains, which is being, first of all; 1) a library of > clones of Max/MSP objects; 2) bringing some level of compatibility between > the platforms; 3) allowing cross platform patches. > >> Indeed, for me backward compatibility more important than Max/MSP >> compatibility. > > > well, we have seemed to open this discussion because of that problem with > the average~ object... it's not really about the object though, it's really > about how you are interfering with the purpose of cyclone, and the action > you're taking is just a reflect on it. > > This is a sensitive issue because you're just killing the purpose of cyclone > to whatever you feel like, which is not clear yet by the way, and that is, > in my opinion, a Fork - you're creating a Cyclone Fork... > > Please be careful with that, and lets discuss if you really want to do that, > and perhaps this list should raise opinions about this. As a cyclone user > (perhaps the only one so far sharing an opinion), I feel really badly about > this. > > But the point I wanna raise is that You do not need to change the purpose of > Cyclone. There's nothing really that should encourage you to hop onboard and > change the course like that. Or is it? We've just touched this discussion > because of a silly object, and I suggested something you could do to avoid > breaking the purpose of cyclone and still maintaining the backwards > compatibility thing if that's important (just create a new/second right > signal outlet that is faithful to the original object). > > If you do that, we don't need to discuss how the purpose is changing, and > there doesn't seem to be any reason why it should. > >> >> Another reason is the limited time I can spend on maintaining cyclone. The >> 4.6 functionality is a useful, but somewhat arbitrary guiding principle. And >> as you observed, most of the missing objects are not that essential... > > > I get the idea that the developers may not keep up with latest developments > in Max/MSP, but that is not a good reason that it Should Not. In fact, it > asks for other people to join in and help with the project and just map what > has been done and still could be essentially done. I've also raised and > reported basically all the last major bugs... > > I have actually been doing that throughly throughout this year in an > extensive research of my own. I'm willing to collaborate. I've mapped a lot > so far, and I ask if my help could be accepted in this project. > > It's not like I have tons of things to do to make cyclone up to the stage of > Max 7.1 - it's just a not that big list of features that have been added to > the objects that I find most relevant and important - average~ being one of > them, since no other object in the Pd world seems to do what it does (it > behaves as very neat and nice average filter). > > >> But enough typing opinions for now, I prefer to do some improvement on >> cyclone objects tonight :-). > > > Well, hope you've made some cool progress, I'm really happy you came up to > help, this is a project that needed attention, but I also think these > opinions are important and I even hoped we had discussed them before. I hope > others in the list could share their thoughts. I'm really concerned here on > the direction this is taking. I hope we can still maintain the main purpose > of cyclone. > > cheers > > _______________________________________________ > Pd-list(a)lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >

7 23

searchpath inside patch
by Achim Bornhoeft 18 Jan '16

18 Jan '16

Is there a possibility to put a statement (relative pathname) inside a patch where to look for additional abstractions, for example to search for abstractions inside a subfolder "abs" which is in the same directory than the patch itself. Thanks for help, Achim

10 17

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Pd-list December 2015