[PD] OS X PD-Extended - help-path question
Hi List A Little question about the helppath-startup flag... I am using Pd version 0.40.3-extended-20080622 on OSX Macbook/Intel The lib/path definitions finally work fine, but i wonder where i have to put an additional -helppath folder. I made a patch where all the mapping - objects are collected, just to have an overview. And if i right click the objects i want the helpfile to open. But instead the abstractions open. Even though the help files are in the help-browser in the subfolder 5.reference/mapping. What should i do ?? 1) Include the startup flag -helppath ... bla bla ? There i dont know if on apple the path has to be in 's 2) Add a new path ? So it doesnt make a difference if is path or helppath ?? 3) Modify the puredata.org.plist file ?? 4) Go back to use a .pdrc-file ?? Thanks... --- Luigi Rensinghoff [EMAIL PROTECTED] skype:gigischinke ichat:gigicarlo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] background color of instances of abstraction
marius schebella wrote: either put a canvas in the background and change it via send/receive This seems like an easy thing, but I get cnv: no method for 'float'. What message could I send to a canvas to make it red? or use sys_gui in combination with hcs/canvas_name which lets you change the font/bg colors of your patch dynamically. That won't do. It seems that the background color of a patch set this way, won't shine through to a parent. So since I'm trying to make is visible which of several instances of the same abstraction is currently running, this seems not to be what I need... -- peace, love harmony Atte http://atte.dk | http://myspace.com/attejensen http://anagrammer.dk | http://modlys.dk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] background color of instances of abstraction
Atte André Jensen wrote: marius schebella wrote: either put a canvas in the background and change it via send/receive This seems like an easy thing, but I get cnv: no method for 'float'. What message could I send to a canvas to make it red? you have to send a message like color 16 to the canvas, for details have a look at the helpfile for canvas (see the subpatch pd edit). or use sys_gui in combination with hcs/canvas_name which lets you change the font/bg colors of your patch dynamically. That won't do. It seems that the background color of a patch set this way, won't shine through to a parent. So since I'm trying to make is visible which of several instances of the same abstraction is currently running, this seems not to be what I need... to bad, you are right. background colors are not working with Graph on parent. I guess that is a bug, sorry, marius. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdlua also into vanilla?
Hans-Christoph Steiner wrote: As a test yes, but not for the release. It's changing too fast right now to maintain backwards compatibility, so including it would cause more problems than it would solve. I am not sure, if it really changes, or if it only adds new features. I think the big problems (file naming, loader) are solved, but not sure. I worked a lot with py/pyext and pdj in the past (which are also candidates for pdx), but pdlua is the only scripting tool that can easily integrate the language as a static library, because it is so small. maintainance should be easier than with python and java. I just had a thought: how about replacing Tcl/Tk with Lua/Tk? Just a thought... is this just a matter of replacing one with the other, or does this mean every graphical part has to be rewritten? marius. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] dumpOSC problems couldn't create
Hi, I'm experiencing some very odd thing. When I open my patch, with a dumpOSC and a OSCRoute, sometimes the dumpOSC box can't be created. As it's not allways I'm sure is not a path problems to the library. As I'm working in something that needs to be kind of stable, I'm getting a bit worried. Using the 39.3 version in a windows xp environment. Any ideas of why that happens or how to solve it? Thanks so much for the help! Maíra _ Conheça o Windows Live Spaces, a rede de relacionamentos do Messenger! http://www.amigosdomessenger.com.br/___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] dumpOSC problems couldn't create
Maíra Sala wrote: Hi, I'm experiencing some very odd thing. When I open my patch, with a dumpOSC and a OSCRoute, sometimes the dumpOSC box can't be created. As it's not allways I'm sure is not a path problems to the library. As I'm working in something that needs to be kind of stable, I'm getting a bit worried. Using the 39.3 version in a windows xp environment. Any ideas of why that happens or how to solve it? [dumpOSC ] needs to be able to bind to network port , if something else is already using it (or if the previous user of the port hasn't timed out completely) then dumpOSC will fail to create. Thanks so much for the help! Maíra _ Conheça o Windows Live Spaces, a rede de relacionamentos do Messenger! http://www.amigosdomessenger.com.br/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] dumpOSC problems couldn't create
Quoting Claude Heiland-Allen [EMAIL PROTECTED]: [dumpOSC ] needs to be able to bind to network port , if something else is already using it (or if the previous user of the port hasn't timed out completely) then dumpOSC will fail to create. which btw, is by design and not a bug. it is the very same behaviour as the [netreceive] object has. and before i forget it: have i already said that i would advice everybody to _not_ use [dumpOSC] (as part of the OSCx library) and instead use mrpeach's [udpreceive] and [unpackOSC]? fadrm IOhannes This message was sent using IMP, the Internet Messaging Program. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] pdlua binaries
hi, I thought, although compiling is very very easy.., for people who don't have xcode installed (which comes with osx 10.5, no??) I put osx 10.5 binaries of pdlua online. http://www.parasitaere-kapazitaeten.net/pdlua_binaries. Somehow I am having troubles with the luagl portion, though. does someone have current examples that work with pdlua 0.5? would it be possible to include luagl in the static build, too? thanks, marius. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] new luagl
hi, here's the code that I am trying to run: require 'luagl' local testgl1 = pd.Class:new():register(testgl1) function testgl1:initialize(name, atoms) self.inlets = 2 self.max = 1 pd.post(tostring(self)) return true end function testgl1:in_1(sel, atoms) if sel == gem_state then testgl1:render(self) end end function testgl1:in_2_float(f) self.max = math.abs(f) pd.post(self.max) end function testgl1:render(myself) max = math.max(myself.max, 1) glBegin(GL_LINE_LOOP) for i=1,max do r = math.random() g = math.random() b = math.random() glColor3d(r, g, b) glVertex2d(math.random(-400,400)/100, math.random(-400,400)/100) end glEnd() end here's the console printout: error: lua: error in dispatcher: [string testgl1]:25: attempt to call global 'glBegin' (a nil value) I think this code was running in lua0.3.. thanks, marius. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
Sorry it took me so long to make something usable out of that mess. I played around with factoring but it seems like it got me nowhere, so I finally just multiplied out all the polynomials to get the usual form. (given input points g[-2] g[-1] g[0] g[1] g[2] g[3] a5 = 3/64*g[-2] + 13/64*g[-1] - 27/32*g[0] + 27/32*g[1] - 13/64*g[2] - 3/64*g[3] a4 = -3/16*g[-2] - 19/64*g[-1] + 63/32*g[0] - 9/4*g[1] + 23/32*g[2] + 3/64*g[3] a3 = 9/32*g[-2] - 9/16*g[-1] + 9/16*g[1] - 9/32*g[2] a2 = -3/16*g[-2] + 5/4*g[-1] - 17/8*g[0] +5/4*g[1] - 3/16*g[2] a1 = 3/64*g[-2] - 19/32*g[-1] + 19/32*g[1] - 3/64*g[2] a0=g[0] output[x]=a5*x+a4)*x+a3)*x+a2*x)+a1)*x+a0 and I did some analysis of the function: This function is continuous up to the 3rd derivative with derivative approximations: g'(0)=3/64*g[-2] - 19/32*g[-1] + 19/32*g[1] - 3/64*g[2] g''(0)=-3/8*g[-2] + 5/2*g[-1] - 17/4*g[0] + 5/2*g[1] - 3/8*g[2] g'''(0)=27/16*g[-2] - 27/8*g[-1] + 27/8*g[1] - 27/16*g[2] but here's the rub. These approximations of the derivatives are horrible. They have terrible spectral response and are not very good for higher frequencies. I'm not sure what this all means in terms of how they sound, but I've got a solid grasp on how this problem works. 1st off: the number of computations is roughly linearly proportional to the number of points, and the degree of the polynomial. 2nd: High frequency response can be obtained by increasing the number of points, beyond the number of points required to constrain the problem for a given degree of polynomial. 3rd: The set of functions specifying the impulse response as sums of (|t|-a)^n*(|t| a) should be used to construct interpolating polynomials for two clear reasons. First, the lowest degree of polynomial, n, that is used determines the number of continuous derivatives (for n=2, there is 1 continuous derivative, for n=4, there are 3 continuous derivatives). Second, n determines the fastest possible rate of attenuation in the stop-band (for n=2, 1/w^3, for n=4, 1/w^5, etc...) In the accompanying graphs, the newest spectrum has been added in magenta. And the question is, where do we go from here are there any remaining problems with tabread's? Is the high-frequency response good enough? Do we need faster attenuation? I think there is little point in trying to increase the rate of attenuation. 1/w^3 is good for a fast interpolator. 1/w^5 should be good enough for a high-accuracy interpolator (in my opinion) so if this were carried out to 8-point, 10-point and so on we could get better high-frequency response. a. I don't know! Chuck attachment: spectrum_tab6.png___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
Chuck, Thanks again for this. Quick question: out of curiosity, how much would this differ from the one which has the standard derivative approximations? Also, if one wanted to put together the one with the standard approximations, would you use the best approximations available for each derivative, or would you use the ones which come from the same series of approximations? I don't know how to call them, but one series of approximation derivations need a 3 points for 1st and 2nd derivatives, and 5 points for 3rd and 4th -- while the next series up needs 5 points for 1st and 2nd and 7 for 3rd and 4th -- can you mix these freely in a 6-point interpolation using the 5-point approximations for everything? I guess one important next direction is to work on the anti-aliasing problem -- you mentioned modulating the interpolation coefficients depending on the speed through the table -- would this be a continuous thing, or would there be a pre-defined set of ideal functions among which to choose? Or would this be a matter of figuring out the linear combination of the appropriate anti-aliasing filter (which might need to change with each sample?) and a standard interpolation function? (or am I totally misunderstanding?) Thanks again, Matt On Sat, Jul 19, 2008 at 3:40 PM, Charles Henry [EMAIL PROTECTED] wrote: Sorry it took me so long to make something usable out of that mess. I played around with factoring but it seems like it got me nowhere, so I finally just multiplied out all the polynomials to get the usual form. (given input points g[-2] g[-1] g[0] g[1] g[2] g[3] a5 = 3/64*g[-2] + 13/64*g[-1] - 27/32*g[0] + 27/32*g[1] - 13/64*g[2] - 3/64*g[3] a4 = -3/16*g[-2] - 19/64*g[-1] + 63/32*g[0] - 9/4*g[1] + 23/32*g[2] + 3/64*g[3] a3 = 9/32*g[-2] - 9/16*g[-1] + 9/16*g[1] - 9/32*g[2] a2 = -3/16*g[-2] + 5/4*g[-1] - 17/8*g[0] +5/4*g[1] - 3/16*g[2] a1 = 3/64*g[-2] - 19/32*g[-1] + 19/32*g[1] - 3/64*g[2] a0=g[0] output[x]=a5*x+a4)*x+a3)*x+a2*x)+a1)*x+a0 and I did some analysis of the function: This function is continuous up to the 3rd derivative with derivative approximations: g'(0)=3/64*g[-2] - 19/32*g[-1] + 19/32*g[1] - 3/64*g[2] g''(0)=-3/8*g[-2] + 5/2*g[-1] - 17/4*g[0] + 5/2*g[1] - 3/8*g[2] g'''(0)=27/16*g[-2] - 27/8*g[-1] + 27/8*g[1] - 27/16*g[2] but here's the rub. These approximations of the derivatives are horrible. They have terrible spectral response and are not very good for higher frequencies. I'm not sure what this all means in terms of how they sound, but I've got a solid grasp on how this problem works. 1st off: the number of computations is roughly linearly proportional to the number of points, and the degree of the polynomial. 2nd: High frequency response can be obtained by increasing the number of points, beyond the number of points required to constrain the problem for a given degree of polynomial. 3rd: The set of functions specifying the impulse response as sums of (|t|-a)^n*(|t| a) should be used to construct interpolating polynomials for two clear reasons. First, the lowest degree of polynomial, n, that is used determines the number of continuous derivatives (for n=2, there is 1 continuous derivative, for n=4, there are 3 continuous derivatives). Second, n determines the fastest possible rate of attenuation in the stop-band (for n=2, 1/w^3, for n=4, 1/w^5, etc...) In the accompanying graphs, the newest spectrum has been added in magenta. And the question is, where do we go from here are there any remaining problems with tabread's? Is the high-frequency response good enough? Do we need faster attenuation? I think there is little point in trying to increase the rate of attenuation. 1/w^3 is good for a fast interpolator. 1/w^5 should be good enough for a high-accuracy interpolator (in my opinion) so if this were carried out to 8-point, 10-point and so on we could get better high-frequency response. a. I don't know! Chuck ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] honk -- update
I am cc'ing the list since I think this is of general interest: The best thing to do would be to make them into a libdir, then users can install them by copying them into the externals folders: http://puredata.info/docs/faq/how-do-i-install-externals-and-help- files-with-pd-extended Basically, create a folder that is named exactly like your library, i.e. 'honk'. Then copy all of the abstractions and help patches into that folder. Then create a 'meta' Pd patch in that folder with the library name, i.e. honk/honk-meta.pd. In that patch you can put info about the library, like the author, copyright, etc. Then to install, users just have to drop that folder into one of the folders listed in that FAQ entry. They'll be able to do [honk/ myobject] as well as [import honk] then [myobject]. .hc On Jul 19, 2008, at 9:29 AM, Johannes Kreidler wrote: hi hans-christoph, now i wanted to have included my honk-abstractions in pd- extended, but how does it work? i'm not pretty familiar with the pd- list. or can i just give it to you (attached)? greets, johannes Hans-Christoph Steiner wrote: On Jan 4, 2008, at 5:13 AM, Johannes Kreidler wrote: hi list, thank you for advices and bug reports. i fixed some things, added another abstractions und help-files. here are the honk abstractions: http://www.kreidler-net.de/honk.html hans-christoph, can it be included in pd-extended? Sure, someone just needs to import them to CVS (soon to be SVN) and then add them to the build system. If you plan on maintaining these, then it would be best if you put them there yourself. Just submit a developer CVS request to pd-dev if you want commit access. .hc greets, johannes honk abstractions collection of abstractions for pd (requires at least pd-extended 0.39) download: http://www.kreidler-net.de/honk.zip help-files are in the same folder, but also included inside the absctractions themselves. GLUE linvert- inverts order of atoms of a list listerize-fifo- like serialize but for symbols, turns a list of symbols into a list, in order: first in first out listerize-lifo- like serialize but for symbols, turns a list of symbols into a list, in order: last in first out mergerize-fifo- turns a stream of symbols into one symbol, in order: first in first out mergerize-lifo- turns a stream of symbols into one symbol, in order: last in first out nbangs- sequence incoming bangs prae- glues a praefix and an input together to one list schange- like change but for symbols, outputs its input only when it changes serialize-fifo- like serialize but for any number of floats. turns a list of floats into a list, in order: first in first out serialize-lifo- like serialize but for any number of floats. turns a list of floats into a list, in order: last in first out TIME malibu- counts in a certain speed zetro- random metronome MATH noreprand- (almost) exactly like random, but without repetitions. outputs random numbers in given range. rondom- like random but with offset as argument TABLES ntables- creates a certain number of tables in subpatch GUI- bak- like bang, but size can be given by argument dac- comfortable control of audio output display- displays a number or symbol in variable size hamp- comfortable horizontal potentiometer hr- like horizontal radio, but number of buttons can be given by argument gop- comfortable graph-on-parent control hs- horizontal slider with range as arguments sf- soundfile-player for different formats (wav, mp3, ogg) tok- like toggle, but size can be given by argument vamp- comfortable vertical potentiometer vr- like vertical radio, but number of buttons can be given by argument vs- vertical slider with range as arguments vum- quick-to-build VU-Meter MISC klist- text-based sequencer with absolute time destinations midi2symbol- MIDI tone numbers to german tone name conversion AUDIO GLUE compress~- every amplitude that lies under a certain threshold will be amplified to a reference amplitude limit~- every amplitude that lies over a certain threshold will be dampened to a reference amplitude pitchshift~- granular transposition AUDIO OSCILLATORS sinesum~- oscillator with various partials waveform~- waveform oscillator (sine/saw/triangle/square/ pulse/ random) -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -
Re: [PD] pdlua also into vanilla?
Le 19 juil. 08 à 16:40, marius schebella a écrit : Hans-Christoph Steiner wrote: As a test yes, but not for the release. It's changing too fast right now to maintain backwards compatibility, so including it would cause more problems than it would solve. I am not sure, if it really changes, or if it only adds new features. I think the big problems (file naming, loader) are solved, but not sure. I worked a lot with py/pyext and pdj in the past (which are also candidates for pdx), but pdlua is the only scripting tool that can easily integrate the language as a static library, because it is so small. maintainance should be easier than with python and java. And what about PHP, it would be nice to have access directly to this language with Pd, there is a lot of people knowing this language and it is useful with MySQL and with query for the web ? It is often installed on computer with Apache server and MySQL with LAMP, MAMP or WAMP. ++ Jack I just had a thought: how about replacing Tcl/Tk with Lua/Tk? Just a thought... is this just a matter of replacing one with the other, or does this mean every graphical part has to be rewritten? marius. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] dumpOSC problems couldn't create
Le 19 juil. 08 à 17:25, [EMAIL PROTECTED] a écrit : Quoting Claude Heiland-Allen [EMAIL PROTECTED]: [dumpOSC ] needs to be able to bind to network port , if something else is already using it (or if the previous user of the port hasn't timed out completely) then dumpOSC will fail to create. which btw, is by design and not a bug. it is the very same behaviour as the [netreceive] object has. This is a real problem with [netreceive]. For example when Pd crash, if you open your last patch, Pd can't create your [netreceive] with the same port. Is it possible to force to close connection on this port to solve the problem ? ++ Jack and before i forget it: have i already said that i would advice everybody to _not_ use [dumpOSC] (as part of the OSCx library) and instead use mrpeach's [udpreceive] and [unpackOSC]? fadrm IOhannes This message was sent using IMP, the Internet Messaging Program. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [nosleep] WAS: how to avoid (most/many/some) readsf~ dropouts
On Fri, Jul 18, 2008 at 08:29:16PM -0400, Mathieu Bouchard wrote: On Wed, 16 Jul 2008, Hans-Christoph Steiner wrote: They are not my namespaces. I neither wrote the code, nor figured out their usage. I just think it is a pretty good system to use. Well, given how much Günter is not there anymore and how much you are there talking about said namespaces, I'd say that they are pretty much yours. They could also be Günter's and yours at once, or only contextually yours to the extent of the conversation that we're having. Whatever it is, I know that you didn't code them, but this is not what I want to concentrate on. Whatever you want to concentrate on, I don't think it's fair to call them Hans' namespaces. There was a lot of discussion on this list and pd-dev about them for a long time, and many developers and users had input into that discussion. I think it's more appropriate to call them 'our' namespaces, meaning the Pd community in general. Just more noise, Chris. --- http://mccormick.cx ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
The interpolation function is a filter. There would be no need to have an anti-aliasing filter and and interpolation function--there's just the one function. We use the fast interpolating function at speeds = 1. But we need a general interpolation function as a function of speed that converges to the original function as the speed decreases to 1. This would provide the needed generality and flexibility, while having the same general characteristics of the fast interpolating function on which it is based. I'm open to any ideas on this thing... I think I need to take my eyes off of interpolation for a while, and stop beating up the pd list with tables :) Right -- wouldn't this be equivalent to doing the (defined) interpolation and the anti-aliasing as a filter in one step? You're modulating the interpolating function to include the effects of the appropriate anti-aliasing filter -- like a one-step sample rate converter. Except, the ratio between the source and target rates is variable. Is this an inappropriate way to be thinking about it? I guess one problem is how speed is measured -- do you just use absolute value of the index delta from one sample to the next (what happens when the index is not a linear function of time)? Or could you fill something like a delay line with past index positions and then use those to find speed as a three- or five-point approximation of the first derivative -- this would add a few samples of delay but might give a better estimate of speed. Sorry to be dense with the questions, but I want to keep up the best I can. =o) I've got two basic ideas that I'm playing with. The first is to modify the interpolation function continuously adding a series of bumps that are spaced exponentially outward from the original function. If there's some good spectral properties, there could be a way to make a smooth transition and hold the number of calculations to O(log(speed)) instead of O(speed) My second idea is to replace the points and their derivatives, with filters (low-pass filters for the points and band-pass filters for the derivatives). Then, fit a polynomial as before and interpolate. Like existing schemes, this could be turned into continuous functions for impulse response, which vary as functions of speed. Any ideas? Can you give a quick example of the form of each idea? In the first, are you adding bumps to the interpolator's impulse response? In the second are you saying you would replace a point with the impulse response of a low-pass filter (e.g. in a 5th-degree polynomial with coefficients a0 a1 a2 a3 a4 and a5, instead of matching a0+a1+a2+a3+a4+a5 with y[1] you'd match it with an impulse response centered on y[1])? Would the algebra still be such that you could keep the form for derivatives of the polynomials (in the last example, 2*a2+6*a3+12*a4+20*a5 as the 2nd derivative at y[1]) even though you're matching them with something other than an approximation? Feeling my way through, Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
