Pd-list September 2015

pd-list@lists.iem.at

62 participants
88 discussions

Start a nNew thread

Re: [PD] Delay time limit bug (was: PVoc patch "bug"?)
by Christof Ressi 22 Sep '15

22 Sep '15

1 0

[PD-announce] ANN: pd-l2ork version 20150917 now available
by Ivica Ico Bukvic 22 Sep '15

22 Sep '15

Apologies for x-posting, Following over dozen minor releases, yesterday pd-l2ork team has unveiled our latest major release, version 20150917. Release highlights include: Release highlights: *Expanded K12 module *Pd-L2Ork can now coexist with other releases without any package conflicts *Drawing optimizations *New convenience functions, like comments with endlines and labels with spaces *Comprehensive Raspberry PI GPIO with PWM and I2S/MCP3008 (for analog ins) support *New version of L2Ork-centric libcwiid library fork offering support for all versions of Nintendo-branded wiimotes, including the new MotionPlus Inside, as well as the support for interleaved passthrough mode (e.g. MotionPlus + Nunchuk) *Code refactoring *Bunch of minor and aesthetic fixes *Last release (barring any major bugs) prior to the next major release featuring node-webkit GUI (node-webkit version is currently in alpha stage of development) For a changelog and a more detailed overview, please visit: http://puredata.info/downloads/Pd-L2Ork/releases/20150917 To download pd-l2ork: http://l2ork.music.vt.edu/main/?page_id=56 NB: Currently only Ubuntu 14.04 64bit build is available, with 32bit and Raspberry Pi builds forthcoming. About Pd-L2Ork Pd-L2Ork is a fork of the ubiquitous Pure-Data focusing on improved user interface, expanded collection of externals, and an advanced SVG-enabled graphical front-end. Originally it was introduced as the core infrastructure for the Linux Laptop Orchestra (L2Ork http://l2ork.icat.vt.edu), and has since expanded to include K-12 learning module with a unique learning environment offering adaptable granularity that has been utilized in over dozen maker workshops and initiatives, including the Raspberry Pi Orchestra program for middle school children introduced in the summer 2014. Today, pd-l2ork is being developed by a growing number of international collaborators and contributors. For additional info L2Ork and pd-l2ork: http://l2ork.icat.vt.edu More about the founding author: http://ico.bukvic.net Best, -- Ivica Ico Bukvic, D.M.A. Associate Professor Computer Music ICAT Senior Fellow Director -- DISIS, L2Ork Virginia Tech School of Performing Arts – 0141 Blacksburg, VA 24061 (540) 231-6139 ico(a)vt.edu www.performingarts.vt.edu disis.icat.vt.edu l2ork.icat.vt.edu _______________________________________________ Pd-announce mailing list Pd-announce(a)lists.iem.at http://lists.puredata.info/listinfo/pd-announce

8 25

Small single board computer recommendations?
by William Huston 22 Sep '15

22 Sep '15

I hope this is relevant to this list! I am having big dreams about what can be done with cheap, tiny computers running PD. Look at the various Laptop Orchestras popping up. So exciting! My minimum specification is: * Pi-like horsepower * 10x buffered ADCs with 12bit precision * 4x high quality isolated 24 bit @ 48 khz audio ins and 4x out I want to build 100, But first I need to build 1. It seems the big disadvantage of an Arduino is it is underpowered vs. a RPi quad core (w/faster CPU, more memory, etc). But it seems people love Arduino due to its IO pins. Many ADCs for controllers and sensors! Whereas the RPi is just the opposite. Also high-quality audio both in and out on a Pi seems like a problem people face. Has anyone fixed the issue yet with USB2 stability yet? Do some people use a Pi for CPU and an Arduinio just for IO? (cf. Arduberry) This seems like what an Udoo is (both in one unit). Udoo comments? Along these lines, I have found I really like the specs of the Wolfson Audio card. The chip it's based on (WM5102) is a 6x6. Any experiences to share? I haven't found a buffered ADC solution for high resolution sensors yet. I'm just starting a search of chips capable of this, and found about 6 so far... So I'm guessing there are several possible boards. Again, any recommendations appreciated (esp. of their voltage ranges can be scaled). Are there any other single board computers I should be looking at which might help keep h/w costs down? Thanks! -- -- May you, and all beings be happy and free from suffering :) -- ancient Buddhist Prayer (Metta)

3 2

Re: [PD] PVoc patch "bug"?
by Alexandre Torres Porres 21 Sep '15

21 Sep '15

I've simplified the patch a lot so many things can be discarded. The window size shouldn't affect anything as the reading point in the delay line is fixed. Now I don't have [vline~] or anything, just a steady signal fed to [vd~], when we get close to the end of the delay line it just gets ruined, and that's all that there is to it. There's no flaw in the patch, nothing I didn't think of. It's really something very mysterious or perhaps a bug. The patch is now simpler and also vanilla compatible. I tried it in the new Pd Vanilla 0.46-7 and I got the same weird behaviour. Check attachment please cheers 2015-09-21 14:12 GMT-03:00 Christof Ressi <christof.ressi(a)gmx.at>: > Well, I just think you're hitting the limit of the delay line. Your window > size is 2048 samples, so inside the subpatch that's 2048/(44,1*4) = 11,6 > ms. But one window is one hop size (2,9 ms) behind, therefore 11,6 ms + 2,9 > ms = 14,5 ms and 1000 ms - 14,5 ms = 985,5 ms --> that's pretty much the > limit you were experiencing. Hope that helps. > > Cheers > *Gesendet:* Montag, 21. September 2015 um 18:27 Uhr > *Von:* "Alexandre Torres Porres" <porres(a)gmail.com> > *An:* "Christof Ressi" <christof.ressi(a)gmx.at>, "pd-list(a)lists.iem.at" < > pd-list(a)lists.iem.at> > *Betreff:* Re: PVoc patch "bug"? > my patch has a little issue, I'm saying the delay line is 60000 ms (this > is for the wrapping objects) when it's only 4000, but that is not a problem > for what I'm asking here as the wrapping doesn't influence anything. It's > just something weird that happens even without the wrapping. > > I wonder what's the principle you'd have for not using cyclone :) > > 2015-09-21 12:32 GMT-03:00 Christof Ressi <christof.ressi(a)gmx.at>: >> >> Hey, >> >> the first thing I noticed: your [delwrite~] is at 4000 ms, but [s >> $0-buff_size] is still fed with 60000 ms... Is this on purpose? >> The second thing: Even if you got the range for [pong~] right, my guess >> is that this will create a sudden jump from the end of the delay line to >> the beginning. You'd need some kind of enveloping to mask the >> discontinuity. Maybe this won't be noticeable if you pass the 'problematic' >> area quickly, but might sound terrible if you stay there. In your case, >> however, it seems that the delay line is simply clipped since you've sent a >> wrong value to [pong~]. >> This is just some remote diagnostics, though, since I don't use any >> cyclone objects as a matter of principle :-D. >> >> Cheers >> >> PS: I didn't put this on the list on purpose, because it's only about a >> specific patch and not something more general. >> >> >> *Gesendet:* Montag, 21. September 2015 um 06:48 Uhr >> *Von:* "Alexandre Torres Porres" <porres(a)gmail.com> >> *An:* "pd-list(a)lists.iem.at" <pd-list(a)lists.iem.at>, "Christof Ressi" < >> christof.ressi(a)gmx.at> >> *Betreff:* PVoc patch "bug"? >> Hi there, still struggling with my circular buffer Phase Vocoder, now >> I've found an issue that has no apparent reason. >> >> Check the attached patch please >> >> the speed is 100% and pitcnh shift is "0", so the signal from vline~ >> stands still in one particular point in the buffer (read from [vd~]). >> >> buffer size is 4000 ms, into the PVoc subpatch is supposed to be "1000" >> for it does oversampling with the overlap of 4 (we've discussed this >> before). Anyway, I'm using sampstoms~ and mstosamps~ to convert in a way >> that works for the patch. >> >> The point is, when getting close to the end of the delay line, things get >> ruined for no reason! The end of the buffer is 1000 ms, not 4000 ms as >> pointed above. You can check my patch and see how that goes. >> >> If the reading point is at somewhere just after the buffer size less a >> window size plus a hop size (around 985 ms) things get bad. >> >> I can't find a reason for that in a million years. Please help >> >> thanks >> >

1 0

reading arrays from an external
by oscar pablo di liscia 21 Sep '15

21 Sep '15

Hi list. I have a question on allocating data and reading it through an external. As I have seen so far, the externals that reads arrays, as tabread, allocate the data in their own memory space. As far as I can understand, this result in a "double allocation" of the data. One in the array itself and the other one in the internal memory space of the instance of the tabread external. The point is that I would like to use an array to hold in memory a considerable amount of data and to make it available to an arbitrary "reader" objects without the need of allocating the data again in each one of the readers. Is it possible to write an external that that reads data from an array "on the fly" without the need of allocating the data in its own memory space? Any help will be most appreciate. Oscar Pablo Di Liscia

3 7

Re: [PD] PVoc patch "bug"?
by Alexandre Torres Porres 21 Sep '15

21 Sep '15

my patch has a little issue, I'm saying the delay line is 60000 ms (this is for the wrapping objects) when it's only 4000, but that is not a problem for what I'm asking here as the wrapping doesn't influence anything. It's just something weird that happens even without the wrapping. I wonder what's the principle you'd have for not using cyclone :) 2015-09-21 12:32 GMT-03:00 Christof Ressi <christof.ressi(a)gmx.at>: > Hey, > > the first thing I noticed: your [delwrite~] is at 4000 ms, but [s > $0-buff_size] is still fed with 60000 ms... Is this on purpose? > The second thing: Even if you got the range for [pong~] right, my guess is > that this will create a sudden jump from the end of the delay line to the > beginning. You'd need some kind of enveloping to mask the discontinuity. > Maybe this won't be noticeable if you pass the 'problematic' area quickly, > but might sound terrible if you stay there. In your case, however, it seems > that the delay line is simply clipped since you've sent a wrong value to > [pong~]. > This is just some remote diagnostics, though, since I don't use any > cyclone objects as a matter of principle :-D. > > Cheers > > PS: I didn't put this on the list on purpose, because it's only about a > specific patch and not something more general. > > > *Gesendet:* Montag, 21. September 2015 um 06:48 Uhr > *Von:* "Alexandre Torres Porres" <porres(a)gmail.com> > *An:* "pd-list(a)lists.iem.at" <pd-list(a)lists.iem.at>, "Christof Ressi" < > christof.ressi(a)gmx.at> > *Betreff:* PVoc patch "bug"? > Hi there, still struggling with my circular buffer Phase Vocoder, now I've > found an issue that has no apparent reason. > > Check the attached patch please > > the speed is 100% and pitcnh shift is "0", so the signal from vline~ > stands still in one particular point in the buffer (read from [vd~]). > > buffer size is 4000 ms, into the PVoc subpatch is supposed to be "1000" > for it does oversampling with the overlap of 4 (we've discussed this > before). Anyway, I'm using sampstoms~ and mstosamps~ to convert in a way > that works for the patch. > > The point is, when getting close to the end of the delay line, things get > ruined for no reason! The end of the buffer is 1000 ms, not 4000 ms as > pointed above. You can check my patch and see how that goes. > > If the reading point is at somewhere just after the buffer size less a > window size plus a hop size (around 985 ms) things get bad. > > I can't find a reason for that in a million years. Please help > > thanks >

1 0

PVoc patch "bug"?
by Alexandre Torres Porres 21 Sep '15

21 Sep '15

Hi there, still struggling with my circular buffer Phase Vocoder, now I've found an issue that has no apparent reason. Check the attached patch please the speed is 100% and pitcnh shift is "0", so the signal from vline~ stands still in one particular point in the buffer (read from [vd~]). buffer size is 4000 ms, into the PVoc subpatch is supposed to be "1000" for it does oversampling with the overlap of 4 (we've discussed this before). Anyway, I'm using sampstoms~ and mstosamps~ to convert in a way that works for the patch. The point is, when getting close to the end of the delay line, things get ruined for no reason! The end of the buffer is 1000 ms, not 4000 ms as pointed above. You can check my patch and see how that goes. If the reading point is at somewhere just after the buffer size less a window size plus a hop size (around 985 ms) things get bad. I can't find a reason for that in a million years. Please help thanks

1 0

Off topic but maybe of interest
by Pall Thayer 20 Sep '15

20 Sep '15

Hi All, I've started a new project titled "Objects of Art". These are a growing collection of JavaScript objects created as works of art. The site allows users to edit the code and experience the changes they make. I just made one that uses the javascript webaudio api to create a simple synthesizer. If any of you have been wanting to experiment with javascript webaudio, you can use this as a playground: http://pallthayer.dyndns.org/objectsofart/index.php?id=6 I expect to make more objects using the webaudio api in the future. I think most of you will immediately pick up on the similarities between the logic in PD and javascript webaudio (especially 'connections'). Anyway, have a look, mess around with the code. If you break it, just refresh the page to get back to the original code. Best r. Pall Thayer -- P Thayer, Artist http://pallthayer.dyndns.org

1 0

getting pd_lua to work on 64- bit Ubuntu 14.04
by Forrest Curo 20 Sep '15

20 Sep '15

For some reason I can't find a pd_lua package for this system... can get it on pd-extended, but not for the straight pd. What to do?

4 7

getting [inlet~] to accept data
by Liam Goodacre 20 Sep '15

20 Sep '15

Many objects (ie. [osc~]) have a sort of a hybrid inlet which accepts both signal and data input. However, the [inlet~] object seems to reject data. If I wanted to build an abstraction with an [inlet~] that accepts both signal and data, is there any other way?

6 5

← Newer
1
2
3
4
5
6
7
8
9
Older →

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 September 2015