Re: [PD] better tabread4~
On Wed, 2 Jul 2008, Matt Barber wrote: Seriously though, I tend to agree with you -- this should explain my unease about searching for every polynomial possibility with a certain number of points. I want to help out as much as I can, but I just don't want to be the one to close a door on an option. While it's good to make software very open-ended in order to not close doors on options, it's best to close a door on an option that both is useless and takes special efforts to support. The distinction I make is that useless features that are simple combinations of existing features are fine, and it's normal to be able to patch silly things, but you really don't have to spend time on code that specifically is not going to be used. On the other hand, doesn't [tabread4~]'s Lagrange interpolator have a continuous 2nd derivative while the [tabread4c~] Hermite one does not? No. A Lagrange interpolator on N points is a polynomial of degree N-1, and so its Nth derivative is a flat zero function without holes, and so it is infinitely differentiable. However, those are pieced together as a disparate mosaïc in a way that is not even C1 (continuous 1st derivative), which is what prompted Cyrille to work on a replacement in the first place. Note that a discontinuous 1st derivative implies that all other orders of derivatives are discontinuous. I don't know what that would mean spectrally, if anything. It's the almost in the almost-arbitrary curves you mention that I don't know how to gauge I mean that if you have one Lagrange cubic going through x[-1] x[0] x[1] x[2] and then a new one going through x[0] x[1] x[2] x[3], how are those two polynomials specially related, other than the three intersections that they need to have? perhaps not in any way that matters, and that must be why [tabread4~] looks wrong. -- intuitively one could imagine that the more pieces of its surrounding environment are matched, the better the interpolation, I wouldn't even claim that as more pieces are matched, the interpolation wouldn't get worse. I'd claim the opposite. Matching too many points exactly is not just pointless, it's harmful. It gives importance to things that shouldn't be important. Matching points approximately is a completely different matter, as long as it's approximate enough that the process doesn't let itself be inappropriately influenced by any single point; but then, that is usually called linear regression (or polynomial regression, etc.) Of course, there's more than a strong possibility that this wheel has already been invented several times over and that the answers have been thoroughly established somewhere. Reinventing the wheel is fun. It's tempting more than a few, every day. The thing that keeps bothering me is that the smart people who designed Pd and Csound both arrived at the Lagrange interpolation, Maybe it's some kind of artistic statement that they made... perhaps it could be called Lagrangism. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] best way to do 1/x
Hallo, Atte André Jensen hat gesagt: // Atte André Jensen wrote: Atte André Jensen wrote: I'm a little confused about loadbang, then. Or maybe not. I guess it's exactly the same... Yes, it is. ;) Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] 3dp texture problem
Hi list, i'm triyng to porting my 3dp app from linux to mac os X (with pd-extended nightly build). In my machine (mac os x 10.4, intel coreduo2) 3dp_draw object doesn't accept any texture from pdp_convert. Simply left object white as if it have no texture. Is this a bug? bye husk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] XML-files
How is it possible to make-XML files useable in Pd. e.g for controlling Thank you in advance markus ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Linux + pd + jack midi?
Josh Lawrence wrote: Hello, There are applications I want to use on Linux that speak only jack midi and not alsa seq. Many of the softsynths I like, however, still use the alsa seq interface. Is there a way to make pd act as a glue between these two? yes no problem. you would just have to implement jack midi for Pd :-( seriously, googling for jack midi gives me as result#4 this link [1] that directs me to http://home.gna.org/a2jmidid/ which seems to do exactly what you want. fgmdsr.a IOhannes [1] http://pin.if.uz.zgora.pl/~trasz/jack-keyboard/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] XML-files
[EMAIL PROTECTED](e)k dio: How is it possible to make-XML files useable in Pd. e.g for controlling not sure what you are after but i am reading an XML file using python via pyext external and returning some data to PD enrike Thank you in advance markus ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] best way to do 1/x
Frank Barknecht wrote: Yes, it is. ;) But slightly more tricky is that send/recieve must have the same problems, but may be more difficult to spot. -- 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] best way to do 1/x
Frank Barknecht wrote: See attached example patch which exploits the current implementation to make the issue visible. [t ...] triggers left to right, don't you mean right to left? -- 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] best way to do 1/x
Atte André Jensen wrote: Frank Barknecht wrote: Yes, it is. ;) But slightly more tricky is that send/recieve must have the same problems, but may be more difficult to spot. indeed, this problem exists. that is why you should use explicit connections and [trigger] whenever possible. on the other hand, i do have plans for a [receive] where you could enforce a certain order (similar to [gemhead]) and since we are there: never use [delay] to enforce a certain execution order (it does work, but usually you will get weird (though totally deterministic) results in more complex setups) fmgasd.r IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] best way to do 1/x
yes, [t ] triggers right to left, that's just a typo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On the other hand, doesn't [tabread4~]'s Lagrange interpolator have a continuous 2nd derivative while the [tabread4c~] Hermite one does not? No. A Lagrange interpolator on N points is a polynomial of degree N-1, and so its Nth derivative is a flat zero function without holes, and so it is infinitely differentiable. However, those are pieced together as a disparate mosaïc in a way that is not even C1 (continuous 1st derivative), which is what prompted Cyrille to work on a replacement in the first place. Note that a discontinuous 1st derivative implies that all other orders of derivatives are discontinuous. I'm with you on the general piecewise Lagrange not being C1, but I don't think it follows that all other orders are discontinuous -- can't they alternate? At any rate, check out the 2nd derivatives of the piecewise cubic Lagrange. I believe that at x=0 it will be y[-1] - 2*y[0] + y[1], while at x=1 it will be y[0] - 2*y[1] + y[2]. Therefore, since the terms match at the points on adjacent pieces, the 2nd derivative is continuous even though the first isn't. I'd imagine you could run into this kind of phenomenon especially with piecewise functions. Not sure what it means for the spectral response of the interpolator, though. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] best way to do 1/x
Hallo, hard off hat gesagt: // hard off wrote: yes, [t ] triggers right to left, that's just a typo Yes, umm, guess I had my hands mixed up. Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Loadbang behavior, WAS: best way to do 1/x
Date: Thu, 03 Jul 2008 09:37:05 +0200 From: Atte Andr? Jensen [EMAIL PROTECTED] Subject: Re: [PD] best way to do 1/x To: pd-list@iem.at Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-15; format=flowed Frank Barknecht wrote: Yes, it is. ;) But slightly more tricky is that send/recieve must have the same problems, but may be more difficult to spot. In my patches I sometimes like to have one global [loadbang] which lives in a subpatch called something like [pd init], with one big [trigger] and a bunch of [send]'s. That way I can control exactly what order things get initialized and I never have to guess or be surprised by the order of loadbangs in several other subpatches. However, just like with any message, if you are sending the same thing in several unrelated directions which all eventually dead-end into a cold inlet, you don't need to worry about the order (as much, anyway). Now that I think about it, wouldn't [loadbang]'s in abstractions necessarily have to go before [loadbang]'s elsewhere in the parent patch, to initialize the internal state of the abstraction before any data can be sent to it? And if this is the case, would this inside-out loadbang order extend to [pd subpatch]'s too? Anyway, if this were the case it would still not be something to rely upon too heavily. BTW, since you mentioned it I believe [send] and [receive] should be included in depth-first control dataflow chains, just like regular connections (it would be a serious design flaw if this weren't the case, I think -- but you're right, it can be harder to track down, and harder still if the send and receive symbols live inside graphical objects...). As a fun experiment, see what happens if you make a control connection loop (also see what happens with an audio loop). It's good to be aware of what happens during various kinds of errors. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] best way to do 1/x
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: Atte André Jensen wrote: Frank Barknecht wrote: Yes, it is. ;) But slightly more tricky is that send/recieve must have the same problems, but may be more difficult to spot. indeed, this problem exists. that is why you should use explicit connections and [trigger] whenever possible. Often the execution order is only important in confined, local areas of the code and there direct connections are used anyway. But indeed sends and receives can lead to subtle bugs with execution order, too. But as eveywhere in Pd, many similar situations come up all the time, so with experience it will become easier to spot them. A typical example which is found in many patches is the global beat counter which counts from 0-15 over and over and sends this to a [s BEAT] receiver. If you want to change e.g. a note pattern every time, the counter restarts from 0, you cannot just use [r BEAT]---[select 0], as that may select the new pattern too late, after the first note has already been played. Here you should use a trigger like 0 ... 15 -- beat counter | [t a a] || |[s PRE-BEAT] | [s BEAT] Then use [r PRE-BEAT]---[select 0]---change pattern. Same for physical modelling with [pmpd]: Link forces have to be computed before you can set the new positions of the masses, so the global metro to drive the pmpd objects also is decorated with a [t b b]. and since we are there: never use [delay] to enforce a certain execution order (it does work, but usually you will get weird (though totally deterministic) results in more complex setups) Word! Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] 3dp texture problem
Just curious, did it work on GNU/Linux? Sounds like the various problems that Gem has with various graphics drivers. .hc On Jul 3, 2008, at 8:27 AM, Husk 00 wrote: Hi list, i'm triyng to porting my 3dp app from linux to mac os X (with pd- extended nightly build). In my machine (mac os x 10.4, intel coreduo2) 3dp_draw object doesn't accept any texture from pdp_convert. Simply left object white as if it have no texture. Is this a bug? bye husk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list Access to computers should be unlimited and total. - the hacker ethic ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Loadbang behavior, WAS: best way to do 1/x
Matt Barber wrote: BTW, since you mentioned it I believe [send] and [receive] should be included in depth-first control dataflow chains, just like regular well, what makes you think that [s]/[r] are not? internally send/receive _are_ indeed regular connections, they are just invisible (and thus do not have the constraints of the more physical connections that cannot (e.g.) cross the patch-boundaries. and of course since you don't see the connections and cannot interact with them) there is no way to insert a execution order forcer, like [trigger]. fgmasdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fft newbie - rifft~ filter
Frank, I wasn't quite sure till now what the overlap argument was for. Thanks for clarifying it. -- David Shimamoto Hallo, [EMAIL PROTECTED] hat gesagt: // [EMAIL PROTECTED] wrote: today I start learning FFT, and after seeing the (hann) windowing function, I realized this (attached) filter with custom frequency response, but I suspect something is wrong here why it sucks (given that it does)? First as others wrote you should use block overlaps. The delay strategy, David (pspunch) suggested isn't necessary with overlap using [block~ 512 4] as the block~ object does an internal delay automatically (four times in this case) Then it's important for windowing that you also *window the outgoing signal* after the inverse FFT, otherwise you get these bad artifacts. Check the I03.resynthesis.pd example in the docs for a complete example, the corresponding chapter in Miller's book and maybe my FFT for dummies guide here: http://footils.org/cms/show/60 (though this doesn't explain overlap) Ciao ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] 3dp texture problem
Hans-Christoph Steiner wrote: Just curious, did it work on GNU/Linux? Sounds like the various problems that Gem has with various graphics drivers. .hc Hi hans, triyed with last pd-exented (from 2008-07-02) on a ubuntu hardy machine with intel 945 chipset and everything work well. So, some driver problem on mac? husk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Thu, 3 Jul 2008, Matt Barber wrote: I'm with you on the general piecewise Lagrange not being C1, but I don't think it follows that all other orders are discontinuous -- can't they alternate? No. Any derivative inherits all discontinuities from the original function. It's a basic fact of life. Therefore, since the terms match at the points on adjacent pieces, the 2nd derivative is continuous even though the first isn't. Ok, well, there's usually a distinction made between a continuous function and one with holes. Even though you can use a limit operator to remove the holes, the result of that is just not the same function... unless you see that through limit-operator-coloured glasses. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Loadbang behavior, WAS: best way to do 1/x
On Thu, 3 Jul 2008, Matt Barber wrote: In my patches I sometimes like to have one global [loadbang] which lives in a subpatch called something like [pd init], with one big [trigger] and a bunch of [send]'s. That way I can control exactly what order things get initialized and I never have to guess or be surprised by the order of loadbangs in several other subpatches. Yes, this is something that you may have to do. You only have to do this when you have to [loadbang] a hot inlet, but when you do have to, it's a mess. This is why I added the init-message in GridFlow: [hello, world] is like [loadbang]ing a world message into [hello]. This greatly reduces the number of loadbangs (or of creation arguments that count as such), and most of all, reduces the amount of scheduling that you have to do on [loadbang]. However, just like with any message, if you are sending the same thing in several unrelated directions which all eventually dead-end into a cold inlet, you don't need to worry about the order (as much, anyway). As long as the cold inlet involved in what any other [loadbang] does... I mean a cold inlet's contents get involved in what a hot inlet does, and if such a hot inlet is triggered through a [loadbang] (perhaps indirectly) then order of the loadbangs matters. Now that I think about it, wouldn't [loadbang]'s in abstractions necessarily have to go before [loadbang]'s elsewhere in the parent patch, Yes, it does. It's topologically sorted... aka inside-out like you said. BTW, since you mentioned it I believe [send] and [receive] should be included in depth-first control dataflow chains, just like regular connections [send] and [receive] are depth-first. To do breadth-first you need use [delay] or [pipe] or any other clock-based object. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] why bother...
hello pd world, i have now come to the conclusion that FLOSS coding is just wasting my time, as i don't want to get abused by some dirty closed-source shameless bastards. so i won't be evolving this cool idea anymore: SimSUI - a Simple SVG User Interface - http://osku.de/simsui but as my first intention was to let it communicate with pd (add OSC to vanilla pd already!;), i would like to dedicate that small idea/code to pd(-list), my first open-source love... i could say do what ever you want with that (lousy) code, but as long as closed-source is not illegal, every one can do what ever they want with every code, so no use to say the obvious... ask me again when the revolution starts! .andre p.s. some ass holes has/will probably software patented the idea anyway, so why bother... ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Thu, 2008-07-03 at 04:01 -0400, Matt Barber wrote: On the other hand, doesn't [tabread4~]'s Lagrange interpolator have a continuous 2nd derivative while the [tabread4c~] Hermite one does not? No. A Lagrange interpolator on N points is a polynomial of degree N-1, and so its Nth derivative is a flat zero function without holes, and so it is infinitely differentiable. However, those are pieced together as a disparate mosaïc in a way that is not even C1 (continuous 1st derivative), which is what prompted Cyrille to work on a replacement in the first place. Note that a discontinuous 1st derivative implies that all other orders of derivatives are discontinuous. I'm with you on the general piecewise Lagrange not being C1, but I don't think it follows that all other orders are discontinuous -- can't they alternate? At any rate, check out the 2nd derivatives of the piecewise cubic Lagrange. I believe that at x=0 it will be y[-1] - 2*y[0] + y[1], while at x=1 it will be y[0] - 2*y[1] + y[2]. Therefore, since the terms match at the points on adjacent pieces, the 2nd derivative is continuous even though the first isn't. I'd imagine you could run into this kind of phenomenon especially with piecewise functions. Not sure what it means for the spectral response of the interpolator, though. yo, i am not too much a math guy, so correct me, if i am talking non-sense, but doesn't the a derivative describe the slope of of the original function at any point? if so, a function with one ore more discontinuities cannot have continuous derivative, because a jump at a certain point would result in a infinitely high value at this point of the derivative. one could argue, that in an analogue continuous world - if the jump is short enough - the peak would be too short to be noticed, but this certainly wouldn't be true in a digital, time discrete domain. after all, i still don't get, how it could be figured out in the digital domain, whether a curve is continuous or not. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] why bother...
Because we need you. Take a break. Then get back to work on your code soldier. Keep your chin up and stay on board for the big win. On Thu, 03 Jul 2008 17:52:19 +0200 Andre Schmidt [EMAIL PROTECTED] wrote: hello pd world, i have now come to the conclusion that FLOSS coding is just wasting my time, as i don't want to get abused by some dirty closed-source shameless bastards. so i won't be evolving this cool idea anymore: SimSUI - a Simple SVG User Interface - http://osku.de/simsui but as my first intention was to let it communicate with pd (add OSC to vanilla pd already!;), i would like to dedicate that small idea/code to pd(-list), my first open-source love... i could say do what ever you want with that (lousy) code, but as long as closed-source is not illegal, every one can do what ever they want with every code, so no use to say the obvious... ask me again when the revolution starts! .andre p.s. some ass holes has/will probably software patented the idea anyway, so why bother... ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Use the source ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] possible to reset phasor~?
On Wed, 2008-07-02 at 23:58 +0200, Atte André Jensen wrote: Peter Plessas wrote: as i remeber from the phasor's helpfile, sending a bang to one of its inlets resets the phase to zero. Sending a float to right inlet resets phase (it seems regardless of the value of the float). not quite true. if yourfloat = int(yourfloat), then yes, the [phasor~] is always resetted to zero. but generally: the second inlet of [phasor~] is used to set the phase, so normally numbers between 0 and 1 are used, which give different results. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] why bother...
One benefit you might consider, is that you can develop your own project, and put it on your resume. There's no one better qualified to adapt your code to commercial software, than you. Not that I've had any kind of professional success. but all that coding experience goes on my resume... On Thu, Jul 3, 2008 at 10:52 AM, Andre Schmidt [EMAIL PROTECTED] wrote: hello pd world, i have now come to the conclusion that FLOSS coding is just wasting my time, as i don't want to get abused by some dirty closed-source shameless bastards. so i won't be evolving this cool idea anymore: SimSUI - a Simple SVG User Interface - http://osku.de/simsui but as my first intention was to let it communicate with pd (add OSC to vanilla pd already!;), i would like to dedicate that small idea/code to pd(-list), my first open-source love... i could say do what ever you want with that (lousy) code, but as long as closed-source is not illegal, every one can do what ever they want with every code, so no use to say the obvious... ask me again when the revolution starts! .andre p.s. some ass holes has/will probably software patented the idea anyway, so why bother... ___ 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] pd clicking with jack/linux
On Tue, 2008-07-01 at 00:32 +0200, Derek Holzer wrote: I run PD as root (not sudo, but real root) for click-free operation. But Ubuntu has this weird thing where you can't be root, you can only sudo. Very strange... anyways, worth a try. of course, you can become 'real' root on ubuntu as well: sudo su pd (which still should be the same as 'sudo pd') or you could give the user 'root' a password so that you simply do: su pd roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd clicking with jack/linux
On Mon, 2008-06-30 at 13:48 -0400, patrick wrote: hi, i don't use pd-extended, but i think it's almost the same. the only option missing is: -nosleep (useful for dual-core). so be sure in qjackctl - setup: Realtime Periods/Buffer: 2 Sample Rate: 44100 (or more) Frames/Period: 256 (i am running at 64 without glitches) then for pd: pd -rt -jack -r 44100 -nosleep -audiobuf 256 -channels 16 -alsamidi -mididev 1 etc... from my experience, there is no point in specifying the samplerate, since pd automatically uses the one used by jackd: you cannot force pd to use a different sr. i wonder, if the same goes for -audiobuf roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] extremely stupid question: playing sample
On Tue, 2008-07-01 at 22:30 +0900, hard off wrote: yeah, and you can use [vline~] if you don't want to loop and also in case you WANT to loop. though it's harder to deal with, in many cases i founded it to be more useful, for instance in all cases, where you need to know, when the loop starts. there is actually only one drawback in using [vline~] as the 'table index driver' - compared to [phasor~]: it doesn't allow to change speed at samplerate (yeah, it is possible, but only by sending sr * times messages per second - very expensive, i suppose). roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Wed, Jul 2, 2008 at 1:51 PM, Matt Barber [EMAIL PROTECTED] wrote: Seriously though, I tend to agree with you -- this should explain my unease about searching for every polynomial possibility with a certain number of points. I want to help out as much as I can, but I just don't want to be the one to close a door on an option. I am only qualified to deliver some of the formulae and maybe do some of the programming, but I don't pack the mathematical guns to do the kinds of analytical work Chuck has been doing. I have a bit of insight on the math of the problem, because I've been working through some examples. And I still don't have an objective idea how to design the right interpolator for the job. Because there's so many possibilities, I think we should employ a few heuristics to guide the design. I think we are working with 3 main types of variations (please suggest more if possible): 1. degree of polynomial 2. number of points 3. setting constraints on derivatives and points My observations: 1. increasing the degree of polynomial allows to increase the rate of stop-band falloff (e.g 1/w^3 is best possible for a cubic, 1/w^5 is best possible for 5th degree) 2. increasing number of points allows improved derivatives, leading to better high-frequency response I think we could even turn this around, and specify aspects of the function, like rate of stop-band falloff and location of -3 dB cutoff frequency (which it turns out, is much lower than the Nyquist frequency). That might be the best case for what we can do. Chuck ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] extremely stupid question: playing sample
On Tue, 2008-07-01 at 10:12 +0200, Atte André Jensen wrote: Hi Ok, I spend too much time trying to figure this out, so I have to chicken in and ask: I want to do something that I think is fairly simple and standard: Load a sample at arbitrary length and play it back at various rates. tabplay~ works fine (byt doesn't transpose), and tabread4~ complains that my array is not a power of 2 + 3. So how do I: 1) play my sample at half speed, one-shot? 2) play my sample at half speed, looped? 3) play my sample at half speed, with loop points set by hand? Sorry if this is too obvious! just let me add, that i find this not trivial (nor stupid) at all. since one works with quite low level primitives in pd, there are lots of ways to implement a certain task, where each of it has its pros and cons. peeking at the 'better tabread4~' thread, there are many strategies to only pitch a sample from table down- and upwards. when looping it also comes to choosing an adequate strategy to avoid click/jumps at loop end/start. there are so many different kinds of samplers, that could be implemented in pd: this topic is actually quite complex. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] Pd-0.40.3-extended-rc2 released
On Sat, Jun 28, 2008 at 6:19 PM, hard off [EMAIL PROTECTED] wrote: 10 minutes to load a patch that used to take 10-15 seconds!! Alright, so I narrowed the big jump in loadtimes to between May 18th (about the same as Vanilla) and May 22nd (between 3-4x slower). The 18th is when the hexloader was added, so I pulled it out of my most recent build and the time went right back to normal. So, sorry to pick on the hexloader some more : ) but it seems it is the culprit. Can anyone confirm? Cheers Luke ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] possible to reset phasor~?
Roman Haefeli wrote: but generally: the second inlet of [phasor~] is used to set the phase, so normally numbers between 0 and 1 are used, which give different results. That makes sense. So sending a .5 would reset the phase to half way through? Thanks for mentioning this. -- 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] extremely stupid question: playing sample
Roman Haefeli wrote: just let me add, that i find this not trivial (nor stupid) at all. Thanks for you uplifting remarks about my intellect :-) But being new at something can make you feel stupid. I'm understanding a bit more every day, though, so maybe all hope is not lost! -- 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] extremely stupid question: playing sample
one drawback in using [vline~] as the 'table index driver' - compared to [phasor~]: it doesn't allow to change speed at samplerate (yeah, it is possible, but only by sending sr * times messages per second - very expensive, i suppose). phasor~ doesn't allow speed change at samplerate either. it allows speed change at block rate. so if you want to work with a metro and vline's triggered every 1ms, it would still have better resolution than a normal phasor for speed changes. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] Pd-0.40.3-extended-rc2 released
i found my problem, which was that pd was going nuts trying to find sssad. once i sorted that out, the loading of my patches didn't take so long. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] extremely stupid question: playing sample
hard off wrote:
phasor~ doesn't allow speed change at samplerate either. it allows speed
change at block rate.
Err, yes it does support samplerate control of speed - the left inlet is
a signal inlet, and I checked the source code to confirm it:
// d_osc.c
static t_int *phasor_perform(t_int *w) {
t_phasor *x = (t_phasor *)(w[1]);
t_float *in = (t_float *)(w[2]); // (1)
t_float *out = (t_float *)(w[3]);
// snip weirdness
while (n--)
{
tf.tf_i[HIOFFSET] = normhipart;
dphase += *in++ * conv;// (2)
*out++ = tf.tf_d - UNITBIT32;
tf.tf_d = dphase;
}
// snip boring bits
}
The line marked (1) gets a signal vector from the dsp graph, and the
line marked (2) increments the phase by each signal element.
Claude
--
http://claudiusmaximus.goto10.org
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
[PD] [GEM] viewing options
Hello everyone, Is there a way to: - hide the menubar (and border lines) of the gemwin? (the menubar message doesn't do it, seems to work only on OSX) - Use fullscreen on the secondary screen of a mulstiscreen display? System: quadcore machine running Windows XP - Pd Extended 0.39.3 - GeForce 8600GT best Jaime -- Jaime E Oliver LR [EMAIL PROTECTED] www.realidadvisual.org/jaimeoliver www-crca.ucsd.edu/ www.realidadvisual.org 9168 Regents Rd. Apt. G La Jolla, CA 92037 USA ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] [GEM] weird rendering order problem
Hello all, I have a very strange problem in rendering order. I have several textured polygons in render orders from 11-35 and a big textured polygon on top with a higher number gemhead, but for some reason it doesn't show on top. I have tried it in a big fat patch (where it fails) and in a simple patch where it succeeds. I also tried in the big fat patch, having everything with positive numbers and the one i want on top with negative rendering numbers, but still doesn't work. What could be causing this?: I suspect one possibility is that I am using many abstractions and/or subpatches, could this corrupt somehow the rendering order? I have tried this in: - quadcore machine running Windows XP - Pd Extended 0.39.3 - GeForce 8600GT - powerbook G4 OSX, GEM 0.91 from cvs best, J -- Jaime E Oliver LR [EMAIL PROTECTED] www.realidadvisual.org/jaimeoliver www-crca.ucsd.edu/ www.realidadvisual.org 9168 Regents Rd. Apt. G La Jolla, CA 92037 USA ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
