Re: [PD] List of important computer music works
We all have our lists, but one useful thing is to check out various course materials for computer music courses at different university/college settings. Sometimes they post listening lists as part of the materials, and you can get an idea of what other people are teaching. On Mon, Oct 14, 2013 at 4:00 PM, Samuel Burt composer.samuel.b...@gmail.com wrote: I've been teaching classes for several years now and always provide examples of electronic music from the origins to the 70s. I've also been integrating a little historical background of modern dance music. What I'm really lacking is a substantial list of important works that have been made possible by personal computers, especially those that incorporate interactivity or couldn't have been made without intense digital processes like FFT or granularization. I'm familiar with a few, but is there already a good list to draw from so I don't get bored from repetition? Works created in Pd are even better for selling the idea of learning to program interactive media. Thanks ___ 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] ipoke~_v.3_test1 for Pd
On Thu, Aug 9, 2012 at 3:03 PM, Alexandre Torres Porres por...@gmail.com wrote: Awesome, in fact I'm particularly interested in doing pitch shift on the fly as well, how do you do that? And what about these limitations of [tabread4~]? I'm getting the idea it's all a matter of better quality in the recording of the audio, is it right or is there any other feature? And moreover, what is variable speed about anyway? I can only make some assumptions, but it'd be good to have a better input on this. Thanks for working on this and sharing it out. Cheers Alex et al., [tabread4~] reads from a table of numbers based on the index you give it. If you give it a fractional index (e.g. 3.427), it will interpolate between the values in the two surrounding points (in the example, between the values stored at indices 3 and 4). It does so by drawing a curve that fits the values at the four surrounding indices, and outputs the value of that curve at your fractional index. In some way, it is trying to fill in between samples, and give you a value of what the sample would have been at that factional index. So, you can read through a table faster or slower than the original sample rate, and [tabread4~] will give you higher quality by filling in the gaps (this is one of the things meant by variable speed). [ipoke~] does this in reverse -- it's a table writer, so the left inlet you give the signal you want to write, and right inlet you give the indices in the table you want to write. If you write into the table fast (e.g. imagine the indices you give it are [0, 4.5, 9, 13.5, 18, 22.5, 27 ...]), it will interpolate over the gaps and give you a lower sound. So far it does linear interpolation, but in the works is cubic interpolation like in [tabread4~]. It can be used for many things like pitch and doppler shifts, and other more experimental things in a way that can be difficult to get with a table reader like [tabread4~]. You can change the speed you go through the table with a [phasor~] for complicated pitch shifts, and you can write backwards into a table as well. [ipoke~] will also let you overdub -- that is, mix the signal you want to write into the table with what is already there. This gives you some flexibility. I'm not sure what you mean by pitch shift on the fly -- can you elaborate? Best, Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ipoke~ ?
Yep, count me in. I'm going to be out for a week but will have email access on my phone. A couple of years ago there was a big discussion about different cubic interpolators, and some of us put together classes and did some benchmarking on the different approaches. I'm not sure how [ipoke~] does what it does, but I'd want to leave the idea of several approaches open (maybe along the lines outlined in this thread) to see what will work best for Pd. Matt On Tue, Jun 19, 2012 at 1:15 PM, Julian Brooks jbee...@gmail.com wrote: Apologies for the delay in responding, I'm also away atm. Katja Matt (and anyone else) - we should contact P.A. and get this moving. It may be best if we formulate an email between us to get the source code, rather than us all contacting him separately, and take it from there. I'm more than happy to keep this on-list (unless it pisses people off) in the spirit of open communication. Perhaps we should fork the topic though? Really good that people are up for this, makes me happy. Cheers, Julian P.S. Something been bugging me about my previous email. I really don't want to in any way denigrate the work that H.C. puts into PdE. What I meant by P.A. only being into vanilla is the robustness and cross platform nature of vanilla and that some of the objects in Extended work on some os's and not others. Or something. Hmmm, perhaps I should just stop digging in this particular hole. Let's not forget that P.A.'s also hardcore Max/MSP so, you know, I've had nearly 3 years of him trying to get a rise out of me about all of this. No question though that he's slowly moving over to our direction these days. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ipoke~ ?
On Sun, Jun 17, 2012 at 3:16 AM, Jonathan Wilkes jancs...@yahoo.com wrote: What does Csound's vdelayxw do: mix or overwrite? It's based on approach A -- mixing a kernel into the buffer, so it mixes automatically. The read head of the delay line zeroes each sample out after reading. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ipoke~ ?
On Sun, Jun 17, 2012 at 1:34 AM, Simon Wise simonzw...@gmail.com wrote: On 17/06/12 12:37, Matt Barber wrote: As far as mixing vs. overwriting is concerned, that actually depends on what it's trying to model. Overwriting is probably right for a looper, but mixing is right for a recording of a moving sound source - and because [poke~] doesn't interpolate it's not an issue (it wouldn't be useful to model a moving sound source). But 'approach B' condenses 4 read samples into 1 write sample, so basically it does the same as [poke]: writing one sample at a time. There is no need for mixing internally. If you want to mix, it can be done externally. In my view, a Pd object need not internalize functions that can be done externally, unless there is a huge performance penalty involved. Here is one use case where mixing as part of the function would be useful. Imagine you're trying to model a sound source moving at mach+ speeds -- let's say it starts 500 meters away from the microphone and plays for 3 seconds, and then it moves toward the microphone at twice the speed of sound until it gets two meters away, and then (against any sensible law of inertia) it turns on a dime and moves away from the mic again at .25 the speed of sound. Much of the sound it generates after it makes the turn will reach the microphone before the sound it was making when it started its approach toward the microphone reaches the mic (since the source overtakes its own previous sound). Not so sure that mixing makes sense in this example if you are trying to model something physical ... something moving that fast (for your example a bullet which is shot out of a rifle then bounces back off something very substantial and hard to produce the trajectory you described) would create a sonic boom (a conical wave front) rather than a sound reversed in time while it was travelling supersonically. You get a kind of 3D bow-wave produced, like a boat in water, rather than neat sound ripples following slowly along behind the source in some kind of overlapping spherical wave front pattern. So you would not want to mix, but rather would need to model the boom followed by the sound produced after the slowdown. I don't know how one would model the sound behind/inside the cone while the object was still travelling supersonically, but might guess it was turbulent and noisy, probably something a bit like the wake of a boat. Also not sure what model you would use to deal with sound produced just before the fast travel, but where the projectile caught up and the sonic boom disrupted the nice spherical wave fronts. But you might want to do a mix for other reasons. Yes, good points, and thanks. But it does make a fun what if -- I guess my scenario is more literally like a write head moving toward a read head faster than the speed of the tape. You're right that it's an utterly different medium than air. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ipoke~ ?
On Sat, Jun 16, 2012 at 12:03 PM, katja katjavet...@gmail.com wrote: On Sat, Jun 16, 2012 at 5:01 PM, Matt Barber brbrof...@gmail.com wrote: The user-settable bound would just be in how they decided to use it. Think of it like [until] -- there's no reason to make the user set an upper iteration bound - the user does that just by using it in a way that doesn't crash Pd (and some until loops are more expensive than others). Maybe you're right. Though [tabwrite4~] would be more complicated to handle than [until], user-tests will indicate wether a 'safety belt' would be desired, it is not a prerequisite for the object's functioning. The main thing I see wrong with what we've been calling approach B is that there isn't a good policy for what to do when 1) the index goes backwards in the table, and 2) what to do when the table already has info in it. One could have settable interpolate on backwards jump (default should probably be no) and settable mix new samples with what's there, or overwrite them. When the index goes backwards in the table, the object should write backwards, like [poke~] does. In my view, the object should always overwrite samples, like [poke~] again. I did my sound-on-sound looper with [poke~] and [tabread4~], a mix can be done externally. (see http://puredata.hurleur.com/sujet-5021-sound-sound-looper-clear-option). Consider the use case where one wants to use the table as a buffer and they write through it and loop back to the beginning of the table when it reaches the end. Let's say the table is 44100 samples long, and the index loops from 44087.3 to 2.1 to start writing the table again. Does it interpolate all the intervening samples BACK through the table, or does it interpolate the 14 or so samples FORWARD through the loop? Or neither? These are all possibilities. As far as mixing vs. overwriting is concerned, that actually depends on what it's trying to model. Overwriting is probably right for a looper, but mixing is right for a recording of a moving sound source - and because [poke~] doesn't interpolate it's not an issue (it wouldn't be useful to model a moving sound source). Note that approach A depends on mixing to work because the interpolation would need to be the emergent result of having mixed kernels into the table. Overwriting would defeat the purpose entirely. Now, if we move forward, we need think about what to name it. [tabwrite~] currently does something that maybe should have been called [tabrecord~], so the [tabwrite4~] name is maybe a little misleading. The delay version could be called [vdw~] -- it would take two signals in and output one signal (there's no reason for it to maintain a multitap-able delay buffer because all the relevant work is done on the write end, so if you need multiple read taps you can just feed it into a [delwrite~] further down). I like the name [tabwrite4~]. Every Pd user is (or will be) familiar with [tabwrite~] already, and [tabwrite4~] will be used in combination with [tabread4~], nothing could be more logical. I think I agree -- the only problem is that we have different analogies. Consider all of the following: [tabread] : [tabread4] (control, with or without interpolation) [tabread4] : [tabread4~] (interpolating, one control and one for signals) [tabwrite] : [poke~] (write at an index using control or signal) [tabwrite~] : [tabplay~] (record a signal to a table, or play a signal from a table) [tabread4~] : [tabwrite4~] (read or write samples at specific index from/to a table with interpolation) [tabwrite~] : [tabwrite4~] (write samples to a table at specific index to a table, with or without interpolation) -- wait, that's not what tabwrite~ does! [tabwrite~] could have been maybe better named [tabrecord~]. [tabwrite] and [poke~] are the analogous objects, so one could make a case for calling it [poke4~] (does the same thing as [poke~] but with interpolation, in the Pd nomenclature). Or maybe [tabwrite4~] would imply to some people that you don't control it with indices, but with an up- or downsampling factor. I think [tabwrite4~] is the best name for what we've been talking about, but the asymmetry with the names of other objects gives me pause. OK, onto the next flight! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ipoke~ ?
As far as mixing vs. overwriting is concerned, that actually depends on what it's trying to model. Overwriting is probably right for a looper, but mixing is right for a recording of a moving sound source - and because [poke~] doesn't interpolate it's not an issue (it wouldn't be useful to model a moving sound source). But 'approach B' condenses 4 read samples into 1 write sample, so basically it does the same as [poke]: writing one sample at a time. There is no need for mixing internally. If you want to mix, it can be done externally. In my view, a Pd object need not internalize functions that can be done externally, unless there is a huge performance penalty involved. Here is one use case where mixing as part of the function would be useful. Imagine you're trying to model a sound source moving at mach+ speeds -- let's say it starts 500 meters away from the microphone and plays for 3 seconds, and then it moves toward the microphone at twice the speed of sound until it gets two meters away, and then (against any sensible law of inertia) it turns on a dime and moves away from the mic again at .25 the speed of sound. Much of the sound it generates after it makes the turn will reach the microphone before the sound it was making when it started its approach toward the microphone reaches the mic (since the source overtakes its own previous sound). Moving toward the mic faster than sound is analogous to moving backwards in the table, and for it to be correct it needs to mix rather than overwrite, and it would be very difficult to maintain separate copies of everything and mix it elsewhere in Pd for anything where the control signal is less predictable. So, maybe this is a totally exceptional case that isn't worth caring about, but I'd like to note that this kind of thing (not necessarily faster-than-speed sound, but the physical model) is exactly the motivation for the movable write into a delay line used in room simulation and/or distance encoding in ambisonics, and I think there ought to be at least a switch at the end of the creation argument line that only interested people would use and everyone else can forget about (that is, if approach B turns out to work well in the first place). Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ipoke~ ?
On Thu, Jun 14, 2012 at 2:56 PM, Charles Henry czhe...@gmail.com wrote: I'm not sure I understood the whole thread so far... let me back up: I'm not sure that you want to write samples of a function to the table for each sample you want to write. You start with two signals (blocks of N), one is the data you want to write, the other is the indexes where you want the variables written. The data you want to write is an evenly spaced signal with spectrum on -1/2 f 1/2. Depending on how closely spaced the indexes are, you get aliasing on side, and on the other you have more spectrum than you need. Close together (data written to buffer slower than normal speed): aliasing. The signal that we're writing to the table has fewer points than what's needed to cover the spectrum of the input signal. If all you did was write 4 points from a constant interpolator, you'd still have the aliasing. Right -- but this is no different from [tabread4~] and the rest -- you'll have aliasing when downsampling on read just as much as on write. On write, though, you can pre-filter the incoming signal if you want to reduce aliasing -- just treat it as a normal oversampled signal that you're going to decimate. Far apart (writing faster): There's evidently a possibility of a perfect reconstruction because you've got more points than you need. I think that can be done with sinc functions, and then you can choose finite-length interpolator functions as approximations. This is the easy part of the problem, if you just ignore how potentially expensive it is :) What I see happening is that you when you write-then-read with tabwrite4~ / tabread4~, you get back a sampling of convolving each of the interpolation functions and the input data. The effect of each sample spreads out to cover 8 samples on the output. The usual use would be to write the table with interpolation and then read straight through it without interpolation when it's time to read. But really, there's nothing preventing anyone from sending the output of, say, [vd~] into another delay with [vd~] -- you just have to know what you're getting into if you're going to use it this way. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ipoke~ ?
On Thu, Jun 14, 2012 at 2:41 PM, Miller Puckette m...@ucsd.edu wrote: I've been thinking about this for some days. I agree there are two fundamentally different approaches (A: deal with each incoming sample independently, for each one adding some sort of filter kernel into the table; or B: advancing systematically through the table, filling each point by interpolating from the input signal). I think in approach A it's better not to attempt to normalize for speed since there would always be a step where you have to differentiate the location pointer to get a speed value and that's fraught with numerical peril. Plus, we don't know how much the 'user' will know about write pointer speed - perhaps there's a natural way to determine that, in which case the numerically robust way to deal is to have the user take care of it appropriately for the situation. Aanyway, if we're simulating a real moving source (my favorite example being lightning) it's physically correct for the amplitude to go up if the source moves toward the listener, even to the point of generating a sonic boom. In the other scenario it seems that the result is naturally normalized, in the sense that a signal of value '1' should put all ones in the table (because how else should you interpolate a function whose value is 1 everywhere?) Scenario (B) would be naturally normalized, but there are a few difficulties with it. First, what would happen if you didn't move the write pointer? In scenario (A) you get the sonic boom, (and depending on the signal and the filter kernel this could fluctuate, and you'll get less of an effect further from ground zero. With scenario (B) you never write into the table at all because without an increment you'll never pass over a sample to write (but note, you will write a sample if the index is an integer). Now, to my mind there are two other things to think about. If someone were to drive the index with white noise, with (A) you're mixing the kernel into the table at random and the result is the emergent effect. It's unclear what (B) should do, though -- first, does a leap backwards from 1024 to 2 interpolate all 1021 intervening samples? If so, then second, does it overwrite those, or mix the result into what's already there? It seems you would not want it to interpolate over those samples if the table were 1024 samples long and the leap represented a wrap back to the beginning, and I suppose mixing vs. overwriting could be settable by the user. Choosing (A) for the moment, for me the design goal would be, if someone writes a gianl equal to 1 and sent it to points 0, a, 2a, 3a, ... within some reasonable range of stretch values _a_, would I end up with a constant (which I wold suggest should be 1/a) everywhere in the table? If not you'd hear some sort of _a_ - dependent modulation. I think you have to put a bound on _a_ - if it's allowed to be unbounded there's no fixed-size kernel that will work, and varying the size of the kernel again involves judging the velocity _a_ from the incoming data which I argued against already. I think this is right, but this brings up another design problem -- most sinc-based filter kernels have a value of 1 at 0 and 0 at all other integers, which usually means that if you were to write directly to integer indices you're writing in single samples rather a kernel (since the value of the kernel would be 0 at the surrounding places in the table). Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ipoke~ ?
But... today I realized why approach B could not work at all for an object which takes float indexes as arguments for writing, like you would expect from [tabwrite4~], [ipoke~] or any variable speed writer: for each perform loop, you get N (=blocksize) signal values and equally many index values, so it would be logical to iterate over N input samples, but in contrast, it would be very complicated to iterate over the output samples and couple these to index values. In fact, it would require yet another interpolation. Approach B would only work fine for an object which has a fixed resampling factor, settable via message. And then, the question how to synchronize it with a [tabread4~] is still open. If it used the same interpolator as tabread4~, you could in principle do approach B -- you'd need a struct that held on the the last samples of the previous block, and offset it by a sample. So, let's say you have a blocksize of 4, the first block of incoming signal is [-0.3, 0.4, 0.6, -0.8], and the index block is [0.2, 1.4, 3.0, 5.8]. The way this could work would be to imagine a previous signal block of [0, 0, 0, 0]. Put the last 0 of that block at index 0.2 and the -0.3 at index 1.4. This crosses sample 1, so you find out where that sample sits as a fraction of the difference between those two indices (in this case 0.6), use [0, 0, -0.3, 0.4] as the four points for interpolation between 0 and -0.3, writing sample one as though you were reading from a table with those four points at 0.6 between the 0 and the -0.3 (so far so good?). Then you put 0.4 at index 3.0. Now your interpolation points are [0, -0.3, 0.4, 0.6] to interpolate between -0.3 and 0.4. Index 2 occurs 0.375 between these samples so you run the interpolation function for that fractional index and write sample at index 2, and then you go ahead and write the 0.4 to index 3. Finally, you put 0.6 at index 5.8. You're interpolating between 0.4 and 0.6, and the points are [-0.3, 0.4, 0.6, -0.8]. Index 4 occurs 0.357143 between the two samples and index 5 occurs 0.714286 between, so you run the interpolator twice for those fractional indices, write those samples. Then you save 0.4, 0.6 and -0.8 (the last the samples of the current block of incoming signal), and 5.8 (the last written index) for the next block. When you have the next block you'll have enough info to interpolate between 0.6 and -0.8 from the last block and between -0.8 and the first sample of this one (these steps were actually implied the first time around), and then you're good to go for the next four samples. If I haven't forgotten a step, the same principle ought to work for any blocksize 4 or larger, and you'd need specialized policies for blocksizes of 1 or 2. Sorry for the length, but sometimes detailed examples can be helpful to get things straight. It's weird how puzzling the task of fractional speed writing is, compared to fractional speed reading. If you think that's puzzling, try fractional speed dating. Better focus on approach A (adding a fractionally delayed kernel into the array for each input sample). Approach A does not in itself impose a preferred kernel type or length, so different options could be offered to the user, varying in performance and precision aspects. Each kernel length, if it is fixed (and zero-phase), would imply a known delay, so the user can reckon with it. As I see it, calculating the resampling factor for normalization purposes need not be spoiled by numerical disasters, as each difference is found from two consecutive input index values, there is no autonomous cumulative effect. Sometimes first-difference for that differentiation is a little fraught. It's kind of the same issue if you wanted to incorporate antialiasing into [tabread4~] -- you need a policy for calculating the speed through the table, and first-difference might not be quite accurate enough. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ipoke~ ?
On Thu, Jun 14, 2012 at 9:23 AM, Julian Brooks jbee...@gmail.com wrote: Been in touch with P.A. (he's my supervisor at Huddersfield) and he would be delighted to have a Pd version of iPoke~. If we get a posse together, or if someone is happy to take it on, he's more than happy to share the source code with us/you/them/it. There's also a new version (v.3) which hasn't been released yet and we can take it from that. We/you should decide who's going to take this on and then we/you can get in touch with P.A. Hi, This is a very nice offer. I think having the code would be very useful, or even just a description of the approach as it relates to what we've been discussing. I'm hesitant to take the lead on coding, but I'm very happy to contribute however I can. M ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ipoke~ ?
Hi, I've been going through the vdelayxw code myself. See comments: On Wed, Jun 13, 2012 at 12:30 PM, katja katjavet...@gmail.com wrote: On Sat, Jun 9, 2012 at 5:18 PM, Matt Barber brbrof...@gmail.com wrote: Csound has a variable write delay opcode that would be worth looking at - the csound website has just been flagged by google for having malicious content so I can't link to the manual page, but the opcode is called vdelayxw. Unfortunately I can not understand the c code of vdelayxw. There's comments for the obvious things but not for the magic numbers and other tricks. But it may be a method for sinc-interpolated resampling. It almost certainly is some kind of windowed sinc, and you're right about the magic numbers. I don't think you need to know for sure what the exact interpolation scheme is to make sense of it, though; my understanding of it is as follows: For both the variable read and variable write delay opcodes in csound, one chooses an interpolation window size - say 32 samples. Now, let's say we're trying to READ from the delay line at sample index 116.33. So we need to interpolate between sample 116 and 117. Given our 32-point interpolation window, the earliest sample that will have an effect on the interpolation is sample 101, and the last one is sample 132, so to find the correct interpolation we need to sum together all the scaled windowed sincs (or whatever convolution kernel is in the interpolation window) for each of those 32 samples, at index 116.33, which gives us our read value. The write works rather in reverse: if we want to write a sample at index 116.33, then we need to calculate the windowed sinc (or whatever) for the input sample centered on 116.33, and MIX (not overwrite) those values for samples 101-132 into those samples. What emerges, then, becomes the cumulative effect of having interpolated: imagine the next sample written is at index 118.54 - you're going to mix its function into samples 103-134, and the overlap with the previous action is going to cause the interpolation to work once those samples reach the read head. In that way, a variable write into a delay line is somewhat easier conceptually -- if it's done this way -- than a [tabwrite4~] would be, because the way the table is read is predetermined. Nothing is ever read until all the relevant input samples have had a chance to affect the output in the appropriate way. On the other hand, think of [tabread4~]: it's interpolation scheme is fixed, no matter what resampling factor. With extreme resampling, aliases may be noticeable. But what the hell, it doesn't sound like the original music anyway, when sped up or down to extremes. That is the difference with an offline resampling job, when the original sound must be preserved insofar the new frequency range allows. In that sense, an interpolation scheme like in [tabread4~] could be used for realtime variable speed writing, leaving the consequences for the user. For example, if you make large jumps through the table, many old samples would simply not be rewritten. But even with interpolation quality requirements so relaxed, it is not by itself clear how the samples should be written. Using sinc-interpolation, each input sample could be written as many samples of a (eventually phase-shifted) sinc function, with amplitude compensation for the overlap. The interpolation scheme of [tabread4~] however can not calculate four output samples based on one input sample, it could only calculate one output sample based on four input samples. Two points here. The last thing you said is not actually true -- each interpolation scheme has an associated convolution function, which can be calculated by imagining what the interpolation would look like for a single sample whose value was 1.0 surrounded by zeroes everywhere else. This 4-point piecewise function can be used to write four samples in its immediate vicinity the same way that the sinc does in the csound example. It seems the bigger question to me is, if you skip somewhere far in the table, you're going to write four samples, and then another four samples somewhere else. Maybe this is OK, but another way to think of what to do would be to imagine the incoming signal as something you're interpolating over the way you would do when reading from a table, in which case a very large index increment if you're writing could be just like a bunch of very small index increments when you're reading. So say you jump ahead 48 samples - one way to do it would be to write ALL 48 samples as an interpolation over the the two input samples. That would open up some other problems, like how to interpret the difference between jumping back in a table vs wrapping back around. Not sure how to deal with that at all (this problem doesn't arise in the delay line version of a variable write because what is represented is always a chunk of time rather than an abstract table of numbers to be used for whatever, so
Re: [PD] ipoke~ ?
Two points here. The last thing you said is not actually true -- each interpolation scheme has an associated convolution function, which can be calculated by imagining what the interpolation would look like for a single sample whose value was 1.0 surrounded by zeroes everywhere else. This 4-point piecewise function can be used to write four samples in its immediate vicinity the same way that the sinc does in the csound example. Meaning, there is also a convolution kernel for linear interpolation? How would it look like? Ah, it would be a simple dirac delta, but the point is, the kernel can be applied time-shifted with fractional delay, matching the fraction in the index. By the way, this also holds for sinc-interpolated resampling as described by Julius O. Smith: a linear interpolation in the sinc-table to make the result more precise. Interpolating the interpolation kernel... The kernel for linear interpolation is a linear ramp from 0.0 to 1.0 and then back down to 0.0. This means that if one were to do linear interpolation in the same way the csound opcode applies the sinc, you would center the peak of this ramp at the fractional index into the table, multiply it by the incoming sample, and then write the values of the ramp at the intersection points of the two nearby samples in the table to those samples. So, say the index is 126.78 and the incoming sample value was -0.45. You'd in effect ramp down from 0.0 to -0.45 over indices 125.78 to 126.78, and then back up to 0.0 from 126.78 to 127.78. As desired, this would intersect with samples at index 126 and 127, and the values would be -0.099 at 126 and -0.351 at 127. So, theoretically you could do the same with Pd's cubic lagrangian interpolation kernel, writing 4 points in the table for every incoming sample. This should work fine with a long interpolation kernel, but I foresee a lot of problems with doing this just for 4 points. Like, imagine you're going to write samples 0, 1, and 2 from the incoming signal to indices 2.3, 45.7, and 89.1. Doing it the way I described with a 4-point interpolator you'd put some values at indices 1-4, 44-47, and 88-91, and leave everything else at 0. Imagine you continued like this for a long time -- you'd have the original signal, each sample of which would be interpolated into 4 points, and each of these little spots would be, separated by long strings of zeroes. This isn't going to play back as the same sound but lower, unless you ran it through a low-pass filter that smoothed this signal over the intervening samples, which I think would be pretty much like using the sinc for interpolating in the first place. I should mention that any time I've ever heard of moving the write head to make a variable delay, it's always with a big interpolation kernel. I'm going to look at a couple of other places - something like csound's spat3d opcode, or Richard Furse's old program vspace would be candidates for getting ideas. Hope this is all clear, and sorry if it's all obvious; sometimes it helps me to think about things to write out my thoughts. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] settable receive again
On Sun, Jun 10, 2012 at 6:10 AM, zmoel...@iem.at wrote:
Quoting Jonathan Wilkes jancs...@yahoo.com:
[s parent-$0-$1]
[r parent-$0-$1]
That probably wasn't clear. I don't want [symbol parent-$0-$1]; inside my
abstractions I want the parent $0 prefixed to $1 as the symbol. In other
words, my abstractions make it so that I don't have to type $0- in every
s/r pair where I want canvas locality which as I said is most of the cases
by far. (My abstractions do other stuff which I wrote about in the
nonlocal
scope thread, but that isn't important to this discussion.)
are you talking about canvas-locality (something Pd has no constructs for),
patch-locality ($0), or hierarchical locality (something like [block~] does,
and which many text-based languages do, e.g. {int foo; if(21){float foo; /*
... */ } }
also, do you want to be able to build abstractions that have the same
property?
One other thing I'm not clear on - is the point to have a convenient
way to ensure locality at patch init, or do you want settable receive
while the patch is running? The latter would provide the former,
obviously, but I wonder if the latter is actually germane to the
original complaint. (The latter would also be in most ways
conceptually the same as dynamic patching connections while the patch
is running...)
Matt
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] ipoke~ ?
Hi, I was away from the list for a long while and missed the [tabwrite4~] conversation -- quite interesting. I have been thinking about this for a while. Depending on the application, there's a further complication, which is whether it would overwrite samples in the table, or mix the incoming signal with samples already there. I don't have access to max so I don't know what ipoke~ does. Csound has a variable write delay opcode that would be worth looking at - the csound website has just been flagged by google for having malicious content so I can't link to the manual page, but the opcode is called vdelayxw. Matt On Sat, Jun 9, 2012 at 6:03 AM, katja katjavet...@gmail.com wrote: On Sat, Jun 9, 2012 at 11:00 AM, Georg Bosch k...@stillavailable.com wrote: things I used ipoke~ for in Max include an array/buffer based looper that allows for overdubs while changing playback speed, and pedal-style delays, where each feedback iteration is pitchshifted (see also discussion here: http://puredata.hurleur.com/sujet-3204-different-ways-implementing-delay-loops For exactly that purpose I was looking for [tabwrite4~] a while ago, see: http://lists.puredata.info/pipermail/pd-list/2012-01/093476.html Indeed [ipoke~] would be useful for many things. Did anyone ask Pierre Alexandre if he is willing to release the code so it can be ported to Pd? Katja ___ 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] ipoke~ ?
On Fri, Jun 8, 2012 at 9:18 AM, Roman Haefeli reduz...@gmail.com wrote: On Mit, 2012-06-06 at 11:07 -0400, Matt Barber wrote: On Wed, 2012-06-06 at 09:53 +0200, Jeppi Jeppi wrote: Hey, I wonder whether there is something similar to Max' ipoke~ (an interpolating buffer~ writer) for Pd. I should need it for some physical modelling and resampling stuff. Otherwise, I could implement it myself. It seems only interpolated reading is available (tabread4~ and similar ones), not writing. This somehow reminds of the thread about settable [receive]. Is there really a need for the ability to do interpolated writing? Conceptually, is there any restriction if it is lacking? Can't everything that employs interpolated writing be achieved with interpolated reading as well? Maybe I'm not thinking hard enough... Roman If you're using it for modeling an acoustic space, for instance, an interpolating write is the proper tool for stationary microphone and moving sources. Interpolated read is more like a moving microphone. Imagine, for instance, how you would calculate the delay time of a sound source moving toward a microphone, from the microphone's point of view. Say it's 50ms away right now, and in a second it will be 40ms away. The correct model of this is not to set an interpolated variable delay read at 50ms right now, and ramp to 40ms over one second - that would be looking 50ms into the past (of the source) right now and 40ms into the past at 1 second from now, where what you need is to look 50ms into the past of the source 50ms from now, and 40ms into the past at 1040ms from now - so you'd need to delay the the signal controlling the variable delay read itself by the appropriate amount, and that signal would have to have the same information in it that you're trying to generate with the read in the first place. This problem is easily solvable with a variable write (assuming for the moment a stationary read) - with a variable write, it is as though you're projecting samples into the read's future -- exactly what you want. You can use the same logic for needing to use variable write into a table rather than a delay line. I see how it seems more logical/simple to model a moving source with a interpolating buffer writer. However, it's possible to model both cases, [moving source / stationary mic], [stationary source / moving mic] with a linear buffer writer and a interpolating buffer reader [1]. [1] http://en.wikipedia.org/wiki/Doppler_effect Roman Right - you can model the doppler effect with either. It's the precise timing of a moving sound source that I don't think you can get with just an interpolated read. Look at the example I gave - say S is a source (make it a periodic signal at 100hz) and M is the mic. Let's say S starts 50ms (in terms of speed of sound) from M at T=0s and stays there for 10 seconds. Then let's say at T=10s S moves linearly toward M such that at T=11s it will be 40ms away, at which point it stops and remains stationary. For the second of movement, there will be an associated doppler shift -- but from the point of view of M, the doppler shift will NOT start at T=10s, but rather at T=10050ms, so if you're trying to do that with an interpolated read, you'll have to delay the signal controlling the delay by 50ms. That's easy enough to do if all motion is linear, but the problem explodes if you want, say, circular motion with a field of stationary mics (e.g. a virtual stereo pair or a b-format ambisonic setup) and room reflections, where direction, polar patterns, and inter-channel timing is important. How would you model, for instance, a source moving in a spiral pattern around and away from a cardioid microphone? You have to delay not just the sound coming from the source but its polar coordinates so that you can model the mic response in real time. It comes down to needing the delay you're trying to generate with the variable read to control the variable read itself. You'd want the same ability with a table as you would with a delay line if you wanted to record and process something ahead of time rather than in real time. Also, there aren't many good ways to model a sound source moving faster than the speed of sound aside from an interpolating write. Room simulation is probably the clearest and most intuitive case for wanting an interpolating write, but one could imagine other physical-modeling scenarios that would require it. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ipoke~ ?
On Wed, 2012-06-06 at 09:53 +0200, Jeppi Jeppi wrote: Hey, I wonder whether there is something similar to Max' ipoke~ (an interpolating buffer~ writer) for Pd. I should need it for some physical modelling and resampling stuff. Otherwise, I could implement it myself. It seems only interpolated reading is available (tabread4~ and similar ones), not writing. This somehow reminds of the thread about settable [receive]. Is there really a need for the ability to do interpolated writing? Conceptually, is there any restriction if it is lacking? Can't everything that employs interpolated writing be achieved with interpolated reading as well? Maybe I'm not thinking hard enough... Roman If you're using it for modeling an acoustic space, for instance, an interpolating write is the proper tool for stationary microphone and moving sources. Interpolated read is more like a moving microphone. Imagine, for instance, how you would calculate the delay time of a sound source moving toward a microphone, from the microphone's point of view. Say it's 50ms away right now, and in a second it will be 40ms away. The correct model of this is not to set an interpolated variable delay read at 50ms right now, and ramp to 40ms over one second - that would be looking 50ms into the past (of the source) right now and 40ms into the past at 1 second from now, where what you need is to look 50ms into the past of the source 50ms from now, and 40ms into the past at 1040ms from now - so you'd need to delay the the signal controlling the variable delay read itself by the appropriate amount, and that signal would have to have the same information in it that you're trying to generate with the read in the first place. This problem is easily solvable with a variable write (assuming for the moment a stationary read) - with a variable write, it is as though you're projecting samples into the read's future -- exactly what you want. You can use the same logic for needing to use variable write into a table rather than a delay line. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] euclidean rhythms
I had a quick read of the paper just now. I might have missed the point altogether, but from what I understand, the results that he gets from the Euclidian algorithm are the same (if you accept a rotation pattern as being equivalent) as what you'd get from the simple rounding of fractions. In other words: let's say you want 5 beats in a grid of 12 (or a 12-sided polygon, if we use his graphical representation), the exact spacing between two beats would be 12/5, or 2.4. The first beat would be 0*2.4= 0. The second beat would 1*2.4 = 2.4, rounded to 2 The third would be 2*2.4 = 4.8, which we round to 5. The fourth would be 3*2.4= 7.2, which we round to 7. The fifth would be 4*2.4 = 9.6, which we round to 10. We now have the pattern x.x..x.x..x. Sorry to be late to this discussion, but: Another way to look at this would be a cycle of the intervals 5 or 7, mod 12. Let's look at 7: 0 7 2 9 4 (mod 12, remember) collecting this yields: x.x.x..x.x.. (a rotation of the above). Note that 5 and 7 are coprime to 12 so you can keep going if you want to, but this is also how the standard pentatonic/diatonic scales are generated in a 12-tone universe. All of this is really well-known in scale theory, of course, and Milton Babbitt formalized the isomorphism between pitch/interval/octave and time-point/duration/meter (although, if you take Bartok's music seriously it would appear he'd been thinking about it explicitly in those terms long before). An interesting principle would be to use the nearest number to half the modulus as the generator (higher or lower: they're isomorphic when you make cycles of them in a modular system). So in 12 you have 5 or 7, in 16 you have 9 or 11, in 9 you have 4 or 5. As in scale theory, using patterns like these creates predictable distributions in the modulus for cycles of given lengths. Matt The way I would do it would be to store the pattern in table; calculate the slice size (e.g. 12/5), then multiply successfully by values from 0 to n-1 (0 to 4, since we want 5 divisions of 12), round that, and then store a 1 at the rounded index values. I'm sure there are plenty of more elegant methods. - martin On 25 May 2011 22:13, Cody Loyd codyl...@gmail.com wrote: Posted this on the PD forum.. but haven't heard anything yet so i thought I'd try here as well. Euclidean Rhythms I am interested in implementing something like THIS: http://www.hisschemoller.com/ in PD. I understand the algorithm for generating the rhythms on paper, but i'm not sure how in Pd to go about doing it. ?I'd imagine that it would involve some pretty heavy 'list surgery' and I'm not too sure how to go about doing it. This website: http://ruinwesen.com/blog?id=216 gives a little more info on how the algorithm works (especially in the PDF he links to, page 2 has the relevant example), and talks about coding the thing in Lisp, but i can't figure it out in PD. any hints? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- next part -- A non-text attachment was scrubbed... Name: not_exactly_euclidian_rhythms.pd Type: application/octet-stream Size: 1966 bytes Desc: not available URL: http://lists.puredata.info/pipermail/pd-list/attachments/20110526/56781f51/attachment.obj -- ___ Pd-list mailing list Pd-list@iem.at to manage your subscription (including un-subscription) see http://lists.puredata.info/listinfo/pd-list End of Pd-list Digest, Vol 74, Issue 83 *** ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Making a Realtime Convolution External
Just scanned the source... big difference would be performance, and if you're picky (you have to be pretty picky, honestly), some difference in accuracy due to floating point's reduced precision at large/small values. Convolution is still expensive enough for performance to really matter. the biggies: - partconv implements a single fixed block size, but freq domain convolution is faster by far on bigger blocks (peak on a core duo is near 4k sample blocks). implementing growing block sizes makes a big difference to low latency performance (e.g. 64 64 128 128 256 256 512 512 1024 1024 2048 2048 4096 4096), as you can get low latency while most of your convolutions operating on the ideal high-performance block size. I was putting one of these together in Pd vanilla with dynamic patching as an exercise a few years back, but there were some problems I had. I think you can just do a simple 64 128 256 512 etc. and let the block delay take care of the timing automatically, but I actually found the kind you posted here to work a little better. Another one that worked even better was something like 64 32 32 64 64 128 128 256 256 etc., which seemed to front-load some of the calculation a little (and with this one and the one you posted, if Pd's block size were 1, you could do the first block as a direct convolution for extreme low-latency). Anyway, this brings up a problem I've been wondering about with Pd -- If you have lots of reblocking going on I have been assuming that if you had, say, one patch blocked at 64, another at 128, and others at 256 512 1024 2048 and 4096, that at the end of the 4096 block all 7 patches will have just finished a block cycle and there will therefore be a CPU spike relative to other places between the beginning and end of the 4096 block as the calculation for all 7 is done. Is there a way in Pd to offset larger blocks by a given number of samples so that the calculation for that block happens at a different time? It's easy enough to delay the samples -- that's not what I want. I want to delay the calculation as well, so that you could deliberately stagger the blocks and more evenly distribute the calculation in cpu-intensive situations. I'm imagining something like two 4096 blocks running say, 64 samples apart so that one is does its calculation while the other is still collecting samples. Matt - vectorization (sse/altivec) of partconv would give a 2-3.5x performance boost -seth ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] List delete carnage - 2 questions
Sure, PD doesn't give you a way to connect an outlet to an inlet of the same object, which is what's needed here to populate the first list with the numbers from 1-180 (it's one way to do it anyway). In this case, I'm using a counter to count up to 180, and on each bang from the [until] the new number goes into the [list prepend], which adds the number to the end of the last list -- but we need to store the last list as the thing to prepend, so it has to go back into the right inlet, and the only good way of doing that is [t a] (you could just use a [list] object, too, but [t a] seems more reliable and what people use most). There are probably plenty of other ways of doing the same thing. Matt On Sun, Mar 27, 2011 at 6:12 PM, J bz jbee...@gmail.com wrote: Hey Matt, Whoo-Hoo. That's splendid. Can I ask you what the [t a] is doing that's looping with the [list prepend]? Just for my own understanding. Bloody marvellous though. All good wishes, Julian On 27 March 2011 16:19, Matt Barber brbrof...@gmail.com wrote: Here's another approach using only list abs stuff (sorry for the messy -- I threw it together quickly). Could use as an abstraction with two inlets -- one on the right which receives a bang to initialize and one on the left that takes incoming numbers from the sensor, and one outlet (the outgoing numbers). Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Am I alone?
On Tue, Mar 22, 2011 at 12:15 AM, ailo ailo...@gmail.com wrote: On 03/21/2011 11:47 PM, Matt Barber wrote: My apologies for that remark -- it's not quite how I meant it. I did not mean this particular discussion or anything anyone here said. What I mean is that the broad what is music discussion overall tends to annoy me and make me sad, sick at heart, etc. In fact it's one that I quite enjoy when the parties are discussing responsibly and in good faith. I suppose I feel the same way about the is there a god or what is god question -- it can be a fun and sometimes even fruitful discussion, but most often there is astonishingly little new territory to cover, many reasons for nasty partisan disputes and so forth. I guess I've had too many potentially distasteful conversations turn to actually distasteful ones, so the discussion (in the broad sense) feels distasteful to me. Nothing any of you have said have made me sad yet. Matt That makes me feel better. I suppose this is a subject that doesn't necessarily belong on this list and most answers on this thread give away the reluctance to discuss it. I don't know if that is a good or a bad thing. Anyway, starts to feel like swimming upstream :). I suppose I don't want to be the what is music police. =o) In my experience, the discussion appears in every musical community I've ever been a part of, especially if that community has some technical interests. And it happens with enough frequency (there was one on the csound list just last month), that it can start to become an ohhh not THIS again kind of discussion, because (again) there is just so little new territory. Recently there have been a number of claims about the evolutionary advantage (if any) of music (Musicians are HOTT! Music is a low-cost drug!) which try to answer what music IS by way of explaining what it is for (note the scare quotes around explaining). This is maybe a little bit new, but in some ways a little more infuriating than normal, because like all evolutionary explanations of behavior it suffers from the is/ought problem. I keep thinking about religion as an analogy -- I can find it very interesting if there is some evolutionary reason for religious belief among our species, but such a fact would say absolutely nothing about whether I should practice a given religion or any at all in 2011. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Am I alone?
If you want a shortcut, take the Modernist approach-- you just completely disregard the aesthetic/cultural/social context in which the art is made, reimagine the art as a self-contained, closed work, and just assume that every artist in the world is either another modernist or some primitive outgrowth of a particular process that can be data mined to add a new layer of complexity to a future modernist project. I don't object, but for some people, this is exactly the type of thing that could cause disillusion. Like, for the person who started this thread, perhaps. For me, that would just be one of many approaches. Not something as fundamental as an ideology, not that we need to define one. The what is music question is the first thing we discuss in my undergraduate composition courses. I usually find that kind of discussion rather crass, but it's important to have it with students who have little experience with modern music beyond Rachmaninov. I have them read some Wittgenstein -- the famous passages at the beginning of the philosophical investigations where he talks about language games and then asks what is a game? and talks about family resemblances. The idea is to explode the essentialist position, which amounts to having tons of sufficient criteria but almost no necessary ones. Then I'm able to refer to the idea throughout the semester when they're inclined not to think of say, music by Ligeti or Berio as music. But really, the whole discussion feels pretty distasteful. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Am I alone?
If you want a shortcut, take the Modernist approach-- you just completely disregard the aesthetic/cultural/social context in which the art is made, reimagine the art as a self-contained, closed work, and just assume that every artist in the world is either another modernist or some primitive outgrowth of a particular process that can be data mined to add a new layer of complexity to a future modernist project. I don't object, but for some people, this is exactly the type of thing that could cause disillusion. Like, for the person who started this thread, perhaps. For me, that would just be one of many approaches. Not something as fundamental as an ideology, not that we need to define one. The what is music question is the first thing we discuss in my undergraduate composition courses. I usually find that kind of discussion rather crass, but it's important to have it with students who have little experience with modern music beyond Rachmaninov. I have them read some Wittgenstein -- the famous passages at the beginning of the philosophical investigations where he talks about language games and then asks what is a game? and talks about family resemblances. The idea is to explode the essentialist position, which amounts to having tons of sufficient criteria but almost no necessary ones. Then I'm able to refer to the idea throughout the semester when they're inclined not to think of say, music by Ligeti or Berio as music. But really, the whole discussion feels pretty distasteful. Matt In retrospect I was afraid, partly because of my bad English, I had made a few remarks that were not very clear, and that they would be easily misunderstood. Or even offensive to someone. However, I would be interested to know what you mean by this discussion being distasteful. -- ailo My apologies for that remark -- it's not quite how I meant it. I did not mean this particular discussion or anything anyone here said. What I mean is that the broad what is music discussion overall tends to annoy me and make me sad, sick at heart, etc. In fact it's one that I quite enjoy when the parties are discussing responsibly and in good faith. I suppose I feel the same way about the is there a god or what is god question -- it can be a fun and sometimes even fruitful discussion, but most often there is astonishingly little new territory to cover, many reasons for nasty partisan disputes and so forth. I guess I've had too many potentially distasteful conversations turn to actually distasteful ones, so the discussion (in the broad sense) feels distasteful to me. Nothing any of you have said have made me sad yet. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sending audio panning with 4 speaker setup
Ambisonics isn't necessarily overkill, but it only gets you direction, not distance -- it's only a 1-dimensional solution, in the sense that you'd be panning around the outside of a circle but not to locations within that circle. It's not terribly CPU expensive. If you do want distance as well you can use some combination of delay, low-pass filtering, and wet-dry mix of any reverb you happen to be using (and if you want to get really ambitious, you can also simulate individual room reflections). This starts to get CPU intensive especially if you're going to be moving sounds around. If they just stay in place, it's not as bad (and the [delwrite~] [vd~] model doesn't actually model moving sources a certain distance from the virtual microphone -- it models a moving microphone, so a simple Pd solution isn't quite available). Matt Hey all, So I'm still scratching my head with controlling audio panning in an x,y grid using 4 speakers. What, at first, seemed like a somewhat trivial problem, upon closer inspection ain't necessarily so. Does anyone have examples of panning with 4 speakers? About the only things I have found so far are: Building upon Hans' [pan_core~] [pan_quad~] from 'nSLAM', which seems to be unavailable for d/l The 'pd-tutorial' patch 3-9-3-1-spatial-quadro.pdhttp://pd-tutorial.com/english/patches/3-9-3-1-spatial-quadro.pd Anyone know about any others? My stereo panning is built upon the square root example in Andy Farnell's book, which I'm really happy with. Ideally I would like to expand upon that. Then of course there is the whole vbap/ambisonics/cubemixer (possible overkill) route too. My concerns before diving into this are threefold. 1. If it's only going to work for the 2 people in the 'sweet-spot' then what's the point? If it makes any difference I'm using some Bose 180 degrees radiating speakers. 2. The piece is for a performer with electronics, with only the electronics coming out of the speakers. So I'm also wondering whether a 5.1 type setup with the performer as the front centre speaker (as such), may be preferable? 3. The piece requires 96 separate pan positions - how cpu intensive is that going to be? It currently works fine in stereo, which is why 2 lots of stereo in an x,y fashion seems initially preferable. I'm aware that it's pretty much impossible with this speaker setup to make everyone in the room have a similar audio experience, and also to map my visual masses from an msd swarm in the GEM window as audible points, but surely it is possible to do this as an x,y grid. I also admit that I don't understand the dsp theory necessary to make the x,y, grid idea happen so if anyone has some pointers regarding that I would be delighted. Cheers, Jb ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sending audio panning with 4 speaker setup
Can you describe your 2d space a little? Is there a reason for wanting 48 discrete spots rather than one continuous space? I actually think the 48 spots could work, but I'm curious how it is supposed to sound when something moves through the space (or do sounds just pop up periodically at those discrete spots)? There is another ambisonic trick I have heard of but haven't yet tried, which is to add a 3rd dimension in the encoding but still decode to a 2d space. The space then becomes a kind of projection of the 3d space onto a 2d space, so you can move closer to the center by increasing the elevation of the direction. Directly upwards in the encoding sends the same signal to all 4 speakers on decode, so that it sounds in the middle of the space. Matt On Mon, Mar 14, 2011 at 10:22 AM, J bz jbee...@gmail.com wrote: Hey Matt, Thanks for pushing my understanding along... I should have said that the pan positions are constantly shifting for 48 separate points within the x-y grid so would be, I presume, heavily cpu intensive with some of the solutions you propose. The patch is running off the performers lappy and is already doing a lot within Pd. My supervisor, the composer Aaron Cassidy, thought that as the GEM window is projected as part of the performance with the msd swarm, that it is somewhat 'dishonest' to only have a stereo field when the visuals are obviously moving on the y plane as well. And annoyingly I have to agree with him. You know when someone has said something and one feels (me in this case) that the genie is out of the bag and there is no going back. Cheers, Julian On 14 March 2011 13:48, Matt Barber brbrof...@gmail.com wrote: Ambisonics isn't necessarily overkill, but it only gets you direction, not distance -- it's only a 1-dimensional solution, in the sense that you'd be panning around the outside of a circle but not to locations within that circle. It's not terribly CPU expensive. If you do want distance as well you can use some combination of delay, low-pass filtering, and wet-dry mix of any reverb you happen to be using (and if you want to get really ambitious, you can also simulate individual room reflections). This starts to get CPU intensive especially if you're going to be moving sounds around. If they just stay in place, it's not as bad (and the [delwrite~] [vd~] model doesn't actually model moving sources a certain distance from the virtual microphone -- it models a moving microphone, so a simple Pd solution isn't quite available). Matt Hey all, So I'm still scratching my head with controlling audio panning in an x,y grid using 4 speakers. What, at first, seemed like a somewhat trivial problem, upon closer inspection ain't necessarily so. Does anyone have examples of panning with 4 speakers? About the only things I have found so far are: Building upon Hans' [pan_core~] [pan_quad~] from 'nSLAM', which seems to be unavailable for d/l The 'pd-tutorial' patch 3-9-3-1-spatial-quadro.pdhttp://pd-tutorial.com/english/patches/3-9-3-1-spatial-quadro.pd Anyone know about any others? My stereo panning is built upon the square root example in Andy Farnell's book, which I'm really happy with. Ideally I would like to expand upon that. Then of course there is the whole vbap/ambisonics/cubemixer (possible overkill) route too. My concerns before diving into this are threefold. 1. If it's only going to work for the 2 people in the 'sweet-spot' then what's the point? If it makes any difference I'm using some Bose 180 degrees radiating speakers. 2. The piece is for a performer with electronics, with only the electronics coming out of the speakers. So I'm also wondering whether a 5.1 type setup with the performer as the front centre speaker (as such), may be preferable? 3. The piece requires 96 separate pan positions - how cpu intensive is that going to be? It currently works fine in stereo, which is why 2 lots of stereo in an x,y fashion seems initially preferable. I'm aware that it's pretty much impossible with this speaker setup to make everyone in the room have a similar audio experience, and also to map my visual masses from an msd swarm in the GEM window as audible points, but surely it is possible to do this as an x,y grid. I also admit that I don't understand the dsp theory necessary to make the x,y, grid idea happen so if anyone has some pointers regarding that I would be delighted. Cheers, Jb ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sending audio panning with 4 speaker setup
Swarms are in! A pal of mine is doing something very similar: http://www.youtube.com/watch?v=Ao258ciSMSg I misunderstood your space before -- you have 48 things that you want to pan around a 2d space, but I thought you meant you wanted to pan stuff around a 2d grid which itself had 48 points. If it were me I'd almost certainly use ambisonics with the projection I mentioned before, but you'd have to do some trigonometry to map x-y to the surface of a half-sphere above the space, and I think you'd have to figure out a way to scale to keep the power the same. The reason I'd use ambisonics is that I would not want to have to redo the engine for a different speaker setup -- I could just throw the encoded stream to another decoder. On the other hand, there are other, simpler ways of doing 4-channel panning if you're committed to a 4-channel setup. There are probably externals I don't know about, or you could model it after something like the Pan4 UGEn in SuperCollider, which uses a simple product of two equal-power curves (using trig functions), one for left-right and one for front-back, such that the front-left speaker gets left*front*input, the back right gets right*back*input, and so forth. The thing about moving stuff around in space like this is that there are some situations (probably not this one) in which you'd want to also simulate doppler shifts. Panning doesn't do this, but you can simulate all that stuff with delay lines (and again, if you really wanted to do it, you'd need a variable delwrite~ rather than a variable delread~ == vd~). On Mon, Mar 14, 2011 at 11:41 AM, J bz jbee...@gmail.com wrote: I probably haven't described the space particularly well, I attach a picture to hopefully explain a little clearer. It's a 'swarm' of [msd] masses and links, with only the masses visible. The swarm is in a zero gravity space so they just float around. The space receives bangs/force at various points on the x-y grid triggered by an accelerometer attached to the performers instrument. So the swarm is in constant motion, sorry if that wasn't clear. At the moment I'm just using the coordinates on the x plane of each mass, which msd handily spits out. I have patched in the option of using the y coordinates but I haven't used them as of yet. Each mass controls the pan position of a partial (of which there are 48) from the instrumentalist and fed into [sigmund~].So the pan position of each mass/partial is slightly different in the (currently) stereo field across 0-1. Hope that helps, Jb On 14 March 2011 14:55, Matt Barber brbrof...@gmail.com wrote: Can you describe your 2d space a little? Is there a reason for wanting 48 discrete spots rather than one continuous space? I actually think the 48 spots could work, but I'm curious how it is supposed to sound when something moves through the space (or do sounds just pop up periodically at those discrete spots)? There is another ambisonic trick I have heard of but haven't yet tried, which is to add a 3rd dimension in the encoding but still decode to a 2d space. The space then becomes a kind of projection of the 3d space onto a 2d space, so you can move closer to the center by increasing the elevation of the direction. Directly upwards in the encoding sends the same signal to all 4 speakers on decode, so that it sounds in the middle of the space. Matt On Mon, Mar 14, 2011 at 10:22 AM, J bz jbee...@gmail.com wrote: Hey Matt, Thanks for pushing my understanding along... I should have said that the pan positions are constantly shifting for 48 separate points within the x-y grid so would be, I presume, heavily cpu intensive with some of the solutions you propose. The patch is running off the performers lappy and is already doing a lot within Pd. My supervisor, the composer Aaron Cassidy, thought that as the GEM window is projected as part of the performance with the msd swarm, that it is somewhat 'dishonest' to only have a stereo field when the visuals are obviously moving on the y plane as well. And annoyingly I have to agree with him. You know when someone has said something and one feels (me in this case) that the genie is out of the bag and there is no going back. Cheers, Julian On 14 March 2011 13:48, Matt Barber brbrof...@gmail.com wrote: Ambisonics isn't necessarily overkill, but it only gets you direction, not distance -- it's only a 1-dimensional solution, in the sense that you'd be panning around the outside of a circle but not to locations within that circle. It's not terribly CPU expensive. If you do want distance as well you can use some combination of delay, low-pass filtering, and wet-dry mix of any reverb you happen to be using (and if you want to get really ambitious, you can also simulate individual room reflections). This starts to get CPU intensive especially if you're going to be moving sounds around. If they just stay in place
Re: [PD] sending audio panning with 4 speaker setup
Probably the best bet would be to make an abstraction for spatializing an individual partial that has the panner built in at the tail which would throw~ the 4 channels to catch~es elsewhere in the patch. Then it wouldn't take much work at all to swap it out with an ambisonic panner later that took the same input sound, X, and Y inputs at a later date. With that deadline maybe I would then make some kind of equal-power quad panner (e.g. the product of a front-back and left-right panner like supercollider's Pan4) or use an external. There's still the CPU question, which might be rather severe with 48 of these going on at once, plus whatever else is going on. I have once in a while needed to sync up two computers via lightpipe and netsend, doing all the control and initial processing on one end and then final processing on the other end... and it's good if timing doesn't have to be sample-perfect. Of course you can't send 48 channels across lightpipe, so maybe you could have one computer calculate all the swarm stuff, do anything with the accelerometer, and run Gem, and just send info via netsend/netreceive to the other which would be running your sigmund~ setup and the spatialization. Note that you're going to have to use line~ for the X and Y panning coordinates so that you don't get discrete jumps in the panning location. Too many options! Matt On Mon, Mar 14, 2011 at 4:40 PM, J bz jbee...@gmail.com wrote: Hey Matt, Well, good to hear the zeitgeist hasn't completely deserted me then:) Yes I'm sorry, I wasn't very clear on what it is I'm working with. That thing of, I've been working for ages on this and can't quite understand why it's not bleedin' obvious to everyone else... So, ambisonics then - eek! Well I have to say my trigonometry is dreadful, not something I'm proud of, just wish I had paid a little more attention in maths classes as a teenager - too busy dreaming of pop stardom and how I would never need any of this stuff. Many is the time when I have heard the ghost of my maths teacher snickering over my shoulder since I got into Pd. I'm gonna do some experimenting and reading up before I dive into anything. There seems to be the Holzmann tutorial, plus all the iem stuff to wade through. The Cubemixer looks interesting but also hefty (back to the possible overkill) and also as msd doesn't work on my usual Puredyne OS I'm moonlighting in W7, so super unsure about compiling stuff in W7 plus the performer runs on a mac, so then setting it up for his machine as well. Aaargh. Plus the 1st performance is now only 2 weeks away! I think the simpler the better basically. Cheers for weighing in though Matt, hopefully speak soon. All the best, Julian On 14 March 2011 17:12, Matt Barber brbrof...@gmail.com wrote: Swarms are in! A pal of mine is doing something very similar: http://www.youtube.com/watch?v=Ao258ciSMSg I misunderstood your space before -- you have 48 things that you want to pan around a 2d space, but I thought you meant you wanted to pan stuff around a 2d grid which itself had 48 points. If it were me I'd almost certainly use ambisonics with the projection I mentioned before, but you'd have to do some trigonometry to map x-y to the surface of a half-sphere above the space, and I think you'd have to figure out a way to scale to keep the power the same. The reason I'd use ambisonics is that I would not want to have to redo the engine for a different speaker setup -- I could just throw the encoded stream to another decoder. On the other hand, there are other, simpler ways of doing 4-channel panning if you're committed to a 4-channel setup. There are probably externals I don't know about, or you could model it after something like the Pan4 UGEn in SuperCollider, which uses a simple product of two equal-power curves (using trig functions), one for left-right and one for front-back, such that the front-left speaker gets left*front*input, the back right gets right*back*input, and so forth. The thing about moving stuff around in space like this is that there are some situations (probably not this one) in which you'd want to also simulate doppler shifts. Panning doesn't do this, but you can simulate all that stuff with delay lines (and again, if you really wanted to do it, you'd need a variable delwrite~ rather than a variable delread~ == vd~). On Mon, Mar 14, 2011 at 11:41 AM, J bz jbee...@gmail.com wrote: I probably haven't described the space particularly well, I attach a picture to hopefully explain a little clearer. It's a 'swarm' of [msd] masses and links, with only the masses visible. The swarm is in a zero gravity space so they just float around. The space receives bangs/force at various points on the x-y grid triggered by an accelerometer attached to the performers instrument. So the swarm is in constant motion, sorry if that wasn't clear. At the moment I'm just using the coordinates on the x
Re: [PD] Toughts on PD vs. Max stability on macintels on, analogindustries.com
You can definite make persistent audio interface settings. The preferred way is to set them in your patch. Preferred by whom ? I can't picture anyone wanting to set anyone else's audio settings when they send someone else a patch. I guess you don't work in anything but 44100 sampling rates. I have done projects that use 22050 and 48k, and both won't work right unless the sampling rate is set correctly. Therefore its an essential property of the patch. But you can often use [samplerate~] in those situations no? There are some times when you have to know the sample rate beforehand, especially in delay situations where an algorithm depends both on the milliseconds of delay AND the actual number of samples. This can happen in reverb and filter design, and elsewhere. Otherwise this is also a problem in more obvious ways when you're playing sound files -- sometimes I'll make my patches so that if it detects the wrong [samplerate~] it tells the user to close the patch and fix it. Which reminds me: there used to be a problem with [delwrite~] where it would allocate its memory when the patch containing it loaded, based on the sample rate active at the time, such that if you switched Pd to a higher sample rate after the patch loaded, you'd have the same maximum number of samples of delay, but not the same maximum milliseconds. I remember there had been talk about fixing this, but if it's still a problem, this might be a reason not to set sample rate from the patch. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Get list of a the arguments of a patch without using any external?
I think Jonathan Wilkes had a different approach as well, which I hope he'll post. MB On Mon, Mar 7, 2011 at 2:28 PM, Matt Barber brbrof...@gmail.com wrote: If you need to get the arguments to use within the abstraction instance itself, you can do it using the [list-argv] patch I've attached (see the help file). It requires a helper subpatch on [list-argv]'s parent (i.e. the abstraction you want to use it in). This employs an idiom by IOhannes which has seemed to be pretty robust. Warning: there is some dynamic patching that goes on in the helper subpatch to make this work. I use this a lot for abstractions that need to be able to take a variable number of arguments. Matt Hello Alexandre, I just try to write an abstraction. I don't know if it could help you, it is just a try. ++ Jack Le lundi 07 mars 2011 ? 11:50 -0500, Alexandre Quessy a ?crit : Hello everyone, I was wondering if there is a way in pure-vanilla Pd to retrieve the list of arguments of an abstraction. I use zexy's [dollarg] for this, but I'm making an effort to see if I can use Pd vanilla only for some abstractions. Is there a way to do this in Pd vanilla? Thanks, -- Alexandre Quessy http://alexandre.quessy.net/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- next part -- A non-text attachment was scrubbed... Name: getArgsAbs.zip Type: application/zip Size: 1514 bytes Desc: not available URL: http://lists.puredata.info/pipermail/pd-list/attachments/20110307/cbf7378f/attachment.zip -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: http://lists.puredata.info/pipermail/pd-list/attachments/20110307/cbf7378f/attachment.pgp -- ___ Pd-list mailing list Pd-list@iem.at to manage your subscription (including un-subscription) see http://lists.puredata.info/listinfo/pd-list End of Pd-list Digest, Vol 72, Issue 29 *** ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] To divide a number in random parts
On Sat, Mar 5, 2011 at 1:06 PM, Mathieu Bouchard ma...@artengine.ca wrote:
On Fri, 4 Mar 2011, Matt Barber wrote:
This all sounds about right -- I made [list-shellsort] more as a
pedagogical exercise for my students
So, what is that supposed to teach them ?
Right, well -- my students are almost all composers with very little
experience with computers, except for maybe music engraving software.
In our computer music program the emphasis has long been on achieving
musical results, and the technical training required to make this
happen tends to be very hard for them. Many of them will look in books
to find things that interest them, only to get scared by equations,
block diagrams, bits of code, etc. They all get really excited about
abstractions in Pd when it comes up, but they don't have any idea why
or when to make them or use them. It's useful, then, to take concrete
problems like sorting numbers, finding roots of quadratic equations,
or making comb filters, for which there exist plenty of code or
diagram examples, and translate them into Pd. At this level just
getting from an analysis of the problem to it works takes a huge
amount of time; analysis of time complexity would be way outside the
scope of the course, unfortunately.
than as a model of speed or efficiency (I did a quicksort as well that
didn't end up in list-abs).
How did you achieve the quicksort ?
Why didn't it end up in list-abs ?
Attached. It uses a table for all the partitioning, and uses until
loops instead of the more classic recursion.
but then it uses fewer of the list abstractions and is less of an
opportunity to show how the abstractions work in action.
Don't you think that it would be better to show the list-abs for what they
are good at, rather than for what they aren't ?
Yes, absolutely. Swapping numbers in a list is hard with vanilla tools
(and I think [list-swap] could be improved considerably) -- my point
was that the library seems to prefer using list operations all the way
through, even if a table/array would be more efficient ultimately.
And it's a good reminder for how slow list manipulations can be.
Ah, yes. But note that [list split] is O(1), which is the cool thing about
pd's lists.
one of the best exercises in constrained patching I've ever done, and fun
for proving that some things are actually possible in vanilla that you think
wouldn't be,
Yeah, people didn't think a pure-vanilla [list-drip] could be O(n) either. I
made one and now it's the new [list-drip]. I didn't mean to actually
encourage people to use list-abs though. I already had written [foreach] in
C++ which is a lot easier to understand :
\class ForEach {
\constructor () {}
\decl 0 list (...) {for (int i=0; iargc; i++) out[0](argv[i]);}
};
\end class {install(foreach,1,1);}
this basically just says : make a class that has an inlet 0 list method that
takes every element and sends it through outlet 0. Then name this class
[foreach] and make it have 1 inlet and 1 outlet.
Your [s2l] looked more desperate though. ;)
Yes, it was desperate. Desperate things happen quite often -- for
instance when an audio chain has a number of if-then conditionals, if
you don't want to use expr~ or externals you have to calculate all the
sidechains and then choose among them arithmetically; there's no good
way to avoid calculation of certain rare conditions (things that
approach division by small numbers, e.g.) on a sample-by-sample basis.
Yet, I suspect that people go ahead and use [list-sort] all the time.
uh, who would do that ?
People who discover list-abs on their own and who then learn that
there's a sort function in the library.
Matt
list-quicksort.pd
Description: Binary data
list-quicksort-help.pd
Description: Binary data
list-sort-compare.pd
Description: Binary data
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] To divide a number in random parts
I attached an example that will do something like what you want, using list abs. Without much trouble you could make this into an abstraction. It follows the first solution someone posted -- pick a bunch of random numbers and then scale them so the total equals the target. I added a few things, though -- it also rounds the numbers to the nearest subdivision that you specify, and it goes through the list and moves anything lower than the min or higher than the max duration to the min or max, compensating elsewhere, until all the durations are in range. I capped the number of searches for outliers to 1000, but you could change that or get rid of it as need be. I haven't tested this thoroughly, so let me know. MB Note that if you sum 1+2+3+4+5+6+7+8+9+10, that's already 55. How many time units do you have per 48 seconds ? (do you have a base tempo at all ?) And then what do you want the distribution to be like ? Is there any maximum duration of a chord, minimum duration of a chord, etc ? It's funny that you said that. I slept over this problem and yes, I want the chords to have a minimun and maximun duration. They don't need to bee all of different durations, the important is this section of the piece to sound like random/chaotic durations, and as we know random numbers (or durations?) sometimes don't look random. I will even make this again for the attacks of individual notes of the chords so the section will have a truly chaotic feeling. And by the way the tempo of this section is quarter = 60 so it's very easy to do this. (thank you Mathieu for making me think about it more deeply) Thank you guys for the other answers. This really helps. Caio Barros random-durations.pd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] To divide a number in random parts
Sorry for the lack of comments. It's kind of a brute-force method; maybe I'll go through and document it at some point, but I just threw it together today to show the concept. A couple of things: if your max and min durations are restrictive you get an awful lot of values at the max and min (whereas you might want to randomize the corrected outliers within a certain range so that you get values that hover a certain random amount above the min or below the max). Also, the total number of beats should be quantized to the nearest subdivision but I didn't worry about that. I guess it's the user's responsibility. Not sure about the go button, seems to work here. At some point you might wish to add a seed for the random if you don't want things to repeat from the last time you opened the patch. Matt On Fri, Mar 4, 2011 at 6:57 PM, Caio Barros caio.bar...@gmail.com wrote: Whoa! Nice! It worked very well here. Although sometimes I have to press the Go button more than once to get different results, even when I change the paramethers. Will do some more testing. I need some time to understand this patch but it looks awesome. 2011/3/4 Matt Barber brbrof...@gmail.com I attached an example that will do something like what you want, using list abs. Without much trouble you could make this into an abstraction. It follows the first solution someone posted -- pick a bunch of random numbers and then scale them so the total equals the target. I added a few things, though -- it also rounds the numbers to the nearest subdivision that you specify, and it goes through the list and moves anything lower than the min or higher than the max duration to the min or max, compensating elsewhere, until all the durations are in range. I capped the number of searches for outliers to 1000, but you could change that or get rid of it as need be. I haven't tested this thoroughly, so let me know. MB Note that if you sum 1+2+3+4+5+6+7+8+9+10, that's already 55. How many time units do you have per 48 seconds ? (do you have a base tempo at all ?) And then what do you want the distribution to be like ? Is there any maximum duration of a chord, minimum duration of a chord, etc ? It's funny that you said that. I slept over this problem and yes, I want the chords to have a minimun and maximun duration. They don't need to bee all of different durations, the important is this section of the piece to sound like random/chaotic durations, and as we know random numbers (or durations?) sometimes don't look random. I will even make this again for the attacks of individual notes of the chords so the section will have a truly chaotic feeling. And by the way the tempo of this section is quarter = 60 so it's very easy to do this. (thank you Mathieu for making me think about it more deeply) Thank you guys for the other answers. This really helps. Caio Barros ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] To divide a number in random parts
Check out [list-sort] for short lists, [list-shellsort] for much longer ones (I don't remember at what point the shellsort starts beating the other one -- maybe if the list has 50 or more entries; but at any rate they do the same thing). Also, if you're going to be doing something like this a ton in real time with long lists, it might be more productive to do all this manipulation with tables instead of lists (but there isn't yet a library of ready-made vanilla table abstractions like list-abs, at least that I know about; it's been on my to do list for a while but I've been busy with lots of other stuff, and anyway there are lots of externals which do these things with tables). Matt On Fri, Mar 4, 2011 at 9:49 PM, Caio Barros caio.bar...@gmail.com wrote: 2011/3/4 Matt Barber brbrof...@gmail.com I'm not shure if I understood that. You mean that if I set the nuber of subdivisions per beat as 10 I can't set the number of beats to, say 8,255? As far as user's responsibility goes, it doesn't make sense to input negative numbers, yet it is possible. I think we're saying the same thing, if you're using the comma the way americans use the dot for indicating decimal; did 8,255 mean 8 + 255/1000? Briefly -- it means that if I set the subdivisions to 4 (i.e. the rhythms will be quantized to sixteenth notes), I will not be able to generate something that lasts a total of 25.2 beats, since 25.2 is quantized to 5 subdivisions per beat (sixteenth-note quintuplets). Oh yes, we are saying the same thing. Sorry for the comma, I always forget that. Even in pd sometimes I keep trying to write 0,25 in a number box and get angry because it doesn't work. One more thing. How hard it is to make possible for the user to choose between the random output that you already made and to sort that output from the smallest to longest duration and vice-versa? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] To divide a number in random parts
This all sounds about right -- I made [list-shellsort] more as a pedagogical exercise for my students than as a model of speed or efficiency (I did a quicksort as well that didn't end up in list-abs). I'm pretty sure that whatever gains come from the algorithm are obliterated by swapping two values in a list -- I think it does bunch of splits to isolate values at two indices and then recopies the entire list TWICE in order to replace the two values. [list-swap] is ridiculously inefficient compared with the array/table analogue -- at one point I had sped up the whole thing vastly by dumping the list to a table first, sorting it all in place, and then dumping it back out to a list -- but then it uses fewer of the list abstractions and is less of an opportunity to show how the abstractions work in action. And it's a good reminder for how slow list manipulations can be. I remember a year or so ago I made a vanilla [list-s2l] that used a bunch of makefilename/sprintf shenanigans to slowly tease apart a symbol into constituent parts, with delimiting: http://lists.puredata.info/pipermail/pd-list/2009-11/074298.html -- one of the best exercises in constrained patching I've ever done, and fun for proving that some things are actually possible in vanilla that you think wouldn't be, but really stupid with comparison to the efficiency of something coded in C for actual use. Yet, I suspect that people go ahead and use [list-sort] all the time. Matt On Fri, Mar 4, 2011 at 10:29 PM, Mathieu Bouchard ma...@artengine.ca wrote: On Fri, 4 Mar 2011, Matt Barber wrote: Check out [list-sort] for short lists, [list-shellsort] for much longer ones (I don't remember at what point the shellsort starts beating the other one -- maybe if the list has 50 or more entries; but at any rate they do the same thing). It vastly depends on the implementation, the interpreter it runs in, and the computer that the interpreter runs on. However, from a short test of running time, it looks like [list-shellsort] runs much slower than what its theory calls the worst case. It probably takes O(n) time to perform stuff that usually takes O(1), probably because it avoids using [tabread] and such. Actually, on my old computer, [list-shellsort] sorts an already-sorted list of size 1000 in 280 ms, and of size 4000 in 5530 ms. That's a 20-fold difference, whereas O(n^2) would be 16-fold, and shellsort's theoretical worst-case would be 8-fold, that is, O(n^1½). [#sort] runs vastly faster than that. For the already-sorted list of size 1000, it does it in something like 0,22 ms, whereas for size 4000 it does it in about 0,90 ms. This means over a thousand times faster than [list-shellsort]. Also, if you're going to be doing something like this a ton in real time with long lists, it might be more productive to do all this manipulation with tables Yes, you would be able to get speeds that are consistently about 10-20 times slower than [#sort] for any table size, which would be a vast improvement over [list-shellsort]. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd suddenly huge in Russia
I have this recurring dream when I'm under deadline for a patch: Cleveland (it's always Cleveland) is going to be attacked by a nuclear weapon, and it is up to ME, armed with Pd, to write a patch that defuses the bomb and saves Cleveland. It is a huge responsibility. is it related to some kind of new non-open source cold war? no way ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pitch envelope
I think it would help me to think of the problem if you could say what you wanted the envelope itself to look/sound like. Is this a continuous glissando (in frequency? pitch?) from low to high? Does it go up then down then up again? Or any of these possibilities? Does it matter more what transpositions are involved or what the timing of the contour is? All of this matters. For instance let's say you had a 1000ms sample, and you want the result of this process to start out an octave lower than the original for a period of time, and then you want it to jump suddenly to an octave higher than the original at some point, such that the total time of this event is 1000ms. Then your timing is determined for you -- you spend 666.667 ms for the octave lower (chewing up 1/3 of the original), and then 333.333 ms for the octave higher (chewing up the remaining 2/3 of the original). But let's say you just want the sound to start some unspecified interval lower than original and then exactly halfway through the 1000ms you leap up to some interval higher than written -- this is a very different problem and it has multiple solutions (that is, it depends on the value of at least one of the intervals). You can start with an octave lower (0.5 playback speed) and then jump at 500ms to a perfect fifth higher (1.5 playback speed). Or you could start a just major third lower (0.8 playback speed) and then jump at 500ms to a just minor third higher (1.2 playback speed). This is true but a little more complicated with glissandi -- it matters a lot whether you care more about the timing or more about the intervals of transposition, and if you care about the intervals it's important whether you're thinking of interval in terms of frequency difference or in terms of pitch (the base-2 log of frequency ratios, i.e. fractions of an octave or semitones or what have you). The linearity of the continuous change will have everything to do with whether you're thinking of frequency or the pitch measurement. I haven't thought this through but I'm pretty sure that a linear envelope on frequency will have the same timing as the average of the endpoint playback speeds -- in the above example, going from 0.5x to 1.5x at 500ms would be the same as linearly changing from 0.5x to 1.5x over the whole 1000ms -- so long as the mean is 1. Matt Herm.. not sure, What I mean is this. If I have a sample of 1000ms, and a breakpoint envelope of 1000ms duration, the two will stay the same length as long as I don't make any points on the graph (i.e. the transpose envelope stays at 0 all the way through). With a transposing sampler, as soon as the transposition is increased the time of the sample playback is decreased, so the transposition envelope will not finish before the sample is played out. Similarly, if the transposition envelope is goes down, the transposition envelope will finish before the sample does. What I am looking for is a mathematical way to calculate the length of a transposition envelope relative to its effect on a finite-length sample, and so to derive a length for the envelope that will allow the envelope and the sample to play out over the same duration. The transposition will continuously change the length of the sample, and so from my limited knowledge of mathematics I reckon it will take some integration of the breakpoint envelope to calculate this number. I'm just not sure how to do this. Best, Ed Metastudio 4 for Pure Data - coming soon! Metastudio 3 still available at http://sharktracks.co.uk/puredata ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Need Help Understanding pack
Check below: On Tue, Feb 8, 2011 at 10:55 PM, Theron Trowbridge theron.trowbri...@gmail.com wrote: That worked very nicely. I had to change the until input to 4 to get it to do the right number of iterations, since the input didn't also kick off the loop, but that's fine. Good -- this looks stylistically correct to me. I'm not sure I understand exactly what was going on before, but I now have a [trigger] object that does the [tabread] first, and then the mod/div math. So I understand why it works now. Just not exactly why it didn't before :) If I remember correctly, it didn't work before because you had connected the output of one object to several inputs in the wrong order. The problem is there's no way to see if it's in the wrong order just by looking at it -- hence the need for [trigger]. So it wasn't a mistake of ordering the connections properly on your part, it was a mistake in not ordering them explicitly with trigger. Now... I have another [pipe 0] object in the button_handler sub-patch which delays a message while a [expr] object does its thing. Replacing it with a [trigger] doesn't work. But it's not coordinated with the other outputs of the [unpack] object. Right -- in this case what you need is to have the incoming list in the correct order. See the attached (also, for something this simple there's probably no reason to use [expr]. In the attached patch I just rotated the order of the incoming list -- but probably you would want to make the lists attached to the toggles in the main patch have the order you want -- the last thing you want to unpack should be the first thing in the list (which may seem like confusing syntax when you're building the lists, but it will get more intuitive once you work with order of operation in Pd for a while). Good Luck, MB Is there an object like [trigger] that has multiple inputs and lets you control the timing of the outputs? [pipe] can take multiple inputs but doesn't have the same right-to-left coordinated output that [trigger] does. The FLOSS manual says that the order you hook things up in part determines the order they do things. But I can't make that make a difference. Thanks, -Theron ^ On Fri, Feb 4, 2011 at 12:50 PM, Theron Trowbridge theron.trowbri...@gmail.com wrote: Thanks! I used [pipe] because I had an obvious timing problem and that was an explicit delay object. Didn't occur to me that [trigger] could control the timing as well. It's use wasn't obvious to me from what I had read about it. I will make the adjustments you suggest and see where I get. I expect I will have more questions. Thanks again, -Theron ^ On Fri, Feb 4, 2011 at 5:17 AM, Matt Barber brbrof...@gmail.com wrote: Hello, Before you go any further in Pd, you should check out the [trigger] object. It's the single most important object in Pd, in my opinion - it will help you get the timing right in these kinds of situations. Trigger forces hot-cold things to happen in the correct order explicitly -- without it you have to rely on the order in which you made the connections, which you can't SEE in the patch. You should use [trigger] instead of the [pipe 0] construction you have as well, the number box should most likely be a message with a zero in it (to hardwire it to zero), and you should probably be sending it to the cold inlet of the [int] (so that it just sets the [int] state rather than passing the zero through once when you set it and then once again on the first bang of the [until]). But again, master the use of [trigger] before you go any further -- multiple lines coming from an object should make you feel uncomfortable until you're sure you're doing it correctly. I hope this helps. MB I've looked over the help patches, the FLOSS manual, and at a number of examples, but I'm clearly missing something. I'm trying to build a proof-of-concept state table for a grid sequencer. I figured out to use an array to store my states, and I can write to and read from the table, except when I'm trying to use pack. The reason for pack is to get the column, row, and state of each button in a range of the state table (will be a single column in my end use, but I'm doing the whole thing for now). Attached is a patch with a 2x2 grid set up and you can click on them and set the state table. That works. It's the lookup part that doesn't. I'm stepping through the entire state table, deriving the column and row from the index and looking up the value of that index. This all works until I send those three pieces of information to a pack object, it re-arranges things in inconsistent manner. Clearly there's either a timing thing or I'm not understanding the data flow of what I'm doing. Or maybe I'm just not getting the point of pack. I'm pretty new to this and every step is a struggle, so any suggestions are welcome. But if there are any tips
Re: [PD] Need Help Understanding pack
Hello, Before you go any further in Pd, you should check out the [trigger] object. It's the single most important object in Pd, in my opinion - it will help you get the timing right in these kinds of situations. Trigger forces hot-cold things to happen in the correct order explicitly -- without it you have to rely on the order in which you made the connections, which you can't SEE in the patch. You should use [trigger] instead of the [pipe 0] construction you have as well, the number box should most likely be a message with a zero in it (to hardwire it to zero), and you should probably be sending it to the cold inlet of the [int] (so that it just sets the [int] state rather than passing the zero through once when you set it and then once again on the first bang of the [until]). But again, master the use of [trigger] before you go any further -- multiple lines coming from an object should make you feel uncomfortable until you're sure you're doing it correctly. I hope this helps. MB I've looked over the help patches, the FLOSS manual, and at a number of examples, but I'm clearly missing something. I'm trying to build a proof-of-concept state table for a grid sequencer. I figured out to use an array to store my states, and I can write to and read from the table, except when I'm trying to use pack. The reason for pack is to get the column, row, and state of each button in a range of the state table (will be a single column in my end use, but I'm doing the whole thing for now). Attached is a patch with a 2x2 grid set up and you can click on them and set the state table. That works. It's the lookup part that doesn't. I'm stepping through the entire state table, deriving the column and row from the index and looking up the value of that index. This all works until I send those three pieces of information to a pack object, it re-arranges things in inconsistent manner. Clearly there's either a timing thing or I'm not understanding the data flow of what I'm doing. Or maybe I'm just not getting the point of pack. I'm pretty new to this and every step is a struggle, so any suggestions are welcome. But if there are any tips or pointers on why pack is not working the way I think it should - or what I should be using to accomplish what I'm trying to do - I would appreciate it. Long-winded description of how the attached patch is behaving: Buttons are arranged in column, row order. I'm just storing 0/1 values in the state_table array. If I click on the first and last buttons, my array is then 1 0 0 1. So state_table[i] gets me the off/on value for the button. i div 2 gets me the column number and i mod 2 gets me the row number. If I just print these three outputs I get everything out in the order I expect: column: 0 row: 0 state: 1 column: 0 row: 1 state: 0 column: 1 row: 0 state: 0 column: 1 row: 1 state: 1 If I send the three values into a pack object and print the output of that, I get: pack: 0 1 0 pack: 0 0 1 pack: 1 1 0 pack: 1 0 0 I would expect this: pack: 0 0 1 pack: 0 1 0 pack: 1 0 0 pack: 1 1 1 So things are coming in the wrong order overall, and the state values are wrong. Thanks, -Theron ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] right outlet of vcf~
What does it do?? It's not used or explained in the help patch. http://crca.ucsd.edu/~msp/techniques/latest/book-html/node157.html ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] one over zed (a conformal function on the complex plane)
What a coincidence -- I woke up with one-over-zed-head myself this morning. made with PureData/GridFlow http://gridflow.ca/gallery/un_sur_z%C3%A8de.jpg (this is actually one screenshot I took from a live video output.) ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] bit crusher abstraction
Attached is a file with the three different formulas I gave last time for two-bit quantization, just for illustration -- any of these could work as a general bit-crusher with a little extra effort. Number one has a variant you can toggle on or off. Also notice how positive max-amp is an exception in numbers one and three -- it can be clipped out though. Matt On Thu, Apr 29, 2010 at 9:56 PM, Matt Barber brbrof...@gmail.com wrote: Reduced bit depth (which is what I think 'bit-crushing' means) can be achieved by dividing the signal by x, pass it through something like [int~], multiply it by x again. An [int~] can be implemented by using [wrap~] and [-~], which are both vanilla. It is also worth considering adding a DC offset. Your [wrap~] solution implements a floor-function, that is, rounding downwards. You can make it round to closest, by adding x/2 before rounding downwards. [expr int($v1)] is rounding zerowards (thus output zero corresponds to a twice bigger input range as any other input). Thus it will behave in a weird unequal way. When the volume gets low, the _effective_ bits-per-sample gets very low, because the relative precision of integers is proportional to amplitude (which is not the case with floats). Therefore, even with 16-bit audio, if your amplitude is 0.0001 times the max, it will feel as if it were 3-bit audio. In such circumstances, the differences between the possible roundings will become quite audible. Bit-depth transitions are really complicated things, especially when going from normalized float to int (and among different utitlities which do this, e.g. libsndfile or ecasound, I've found several different standards). The biggest problem is what to do with the asymmetry about zero with int representations -- there are more negative numbers than positive in a two's complement int system. Here are three formulas I've used for noise-shaping dither in csound (the first one is more compatible with the bit-depth transitions that occur when csound writes a file). let X = the input signal and N = target bits: 1) Y=(floor([2^(N-1)]*X)+0.5)/[2^(N-1)] 2) Y=floor([2^(N-1)]*X+0.5)/[2^(N-1)] 3) Y=floor([2^(N-1)]*X)/[2^(N-1)] The only difference is whether the 0.5 is added, and whether it's added before or after the floor function. So let's say you're moving from floats (-1 to +1) to 8-bits: In the first, one multiplies the signal by 2^7, getting a signal which varies from -128 to +128 (floats). Flooring that will result in ints in the same range (+128 after the floor will be a relative rarity in real signals, though, so the effective range is -128 to 127). Adding 0.5 to all of that gives a range of -127.5 to 127.5 (with the very rarely encountered 128.5). Then division by 128 gives a signal which varies between two values equally spaced from 0, but a constant 0 in will result in a DC-offset out (it's a mid-rise function with 256 possible values). In the second, one multiplies the signal by 2^7, getting a signal which varies from -128 to +128 (floats). Adding 0.5 to this will result in a signal that varies between -127.5 to +128.5, and flooring this gives -128 to +128 (ints). This time, +128 will not be as rare. This also is really just a rounding function, with x.5 values rounded up. It's a mid-tread function, so zeros in will result in zeros out. At first glance it may seem as though this has one more than 2^8 values (128 negative values, 128 positive values, and 0 = 257 total possible values). However, if one were to graph the rounding function, one would find that anything that started out between -127.5 and +127.5 will be rounded to -127 to +127 (255 values), while anything lower than -127.5 will round to -128, and anything higher than 127.5 will round to +128 -- the extremes of the staircase function have half-quantization-step mappings, so the total effect is still 8-bit. This one has the advantage that both zero in and maxamp (positive or negative) give correct output values as well, but the disadvantage that one of the quantized steps is divided between the top and the bottom of the total range. Also, its graph is a reflection of that of the first function about a diagonal. In the third, one starts with the same math as the first, up to the floor function, which gives an effective range of -128 to 127. Then one simply divides by the original scalar, which just gives the mid-tread version of the function from the first formula (the first formula minus half the quantization step), with zeros-in-zeros out but one extra negative value than positive. Maybe sometime later I could post some pictures for two-bit audio. I'm sure there are plenty on the web. There's also the question of whether, even for a bit-crushing effect, one would add dither. Matt bitcrushers.pd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account
Re: [PD] problems using pd with 120 dpi
I'm using Pd version 0.42.5-extended-20100428 and Ubuntu Lucid 10.04 :-) Am 2010-04-28 20:07, schrieb Thomas Holzmann: Hello, I'm using the latest pd-extended and have display problems when using pd on a screen which is set to 120 dpi. Then most of the texts don't fit into the boxes. When I change the screen to 96 dpi everything works fine. I assume that's a problem with tk scaling!? Does someone know a solution for this? On Fedora/CCRMA I use the following stupid wrapper (it's a hack). #!/bin/bash shopt -s -o monitor xrdb -merge /usr/local/lib/pd_fonthelper /usr/bin/pd $@ sleep 1 xrdb -merge /etc/X11/Xresources fg 1 pd_fonthelper is just: Xft.dpi: 72 Obviously you would change this to fit whatever dpi was working for you before. I also had to comment out some lines in pd.tk which test for 8.5 and change font size accordingly; once I did, all my Pd font problems melted away. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] bit crusher abstraction
Reduced bit depth (which is what I think 'bit-crushing' means) can be achieved by dividing the signal by x, pass it through something like [int~], multiply it by x again. An [int~] can be implemented by using [wrap~] and [-~], which are both vanilla. It is also worth considering adding a DC offset. Your [wrap~] solution implements a floor-function, that is, rounding downwards. You can make it round to closest, by adding x/2 before rounding downwards. [expr int($v1)] is rounding zerowards (thus output zero corresponds to a twice bigger input range as any other input). Thus it will behave in a weird unequal way. When the volume gets low, the _effective_ bits-per-sample gets very low, because the relative precision of integers is proportional to amplitude (which is not the case with floats). Therefore, even with 16-bit audio, if your amplitude is 0.0001 times the max, it will feel as if it were 3-bit audio. In such circumstances, the differences between the possible roundings will become quite audible. Bit-depth transitions are really complicated things, especially when going from normalized float to int (and among different utitlities which do this, e.g. libsndfile or ecasound, I've found several different standards). The biggest problem is what to do with the asymmetry about zero with int representations -- there are more negative numbers than positive in a two's complement int system. Here are three formulas I've used for noise-shaping dither in csound (the first one is more compatible with the bit-depth transitions that occur when csound writes a file). let X = the input signal and N = target bits: 1) Y=(floor([2^(N-1)]*X)+0.5)/[2^(N-1)] 2) Y=floor([2^(N-1)]*X+0.5)/[2^(N-1)] 3) Y=floor([2^(N-1)]*X)/[2^(N-1)] The only difference is whether the 0.5 is added, and whether it's added before or after the floor function. So let's say you're moving from floats (-1 to +1) to 8-bits: In the first, one multiplies the signal by 2^7, getting a signal which varies from -128 to +128 (floats). Flooring that will result in ints in the same range (+128 after the floor will be a relative rarity in real signals, though, so the effective range is -128 to 127). Adding 0.5 to all of that gives a range of -127.5 to 127.5 (with the very rarely encountered 128.5). Then division by 128 gives a signal which varies between two values equally spaced from 0, but a constant 0 in will result in a DC-offset out (it's a mid-rise function with 256 possible values). In the second, one multiplies the signal by 2^7, getting a signal which varies from -128 to +128 (floats). Adding 0.5 to this will result in a signal that varies between -127.5 to +128.5, and flooring this gives -128 to +128 (ints). This time, +128 will not be as rare. This also is really just a rounding function, with x.5 values rounded up. It's a mid-tread function, so zeros in will result in zeros out. At first glance it may seem as though this has one more than 2^8 values (128 negative values, 128 positive values, and 0 = 257 total possible values). However, if one were to graph the rounding function, one would find that anything that started out between -127.5 and +127.5 will be rounded to -127 to +127 (255 values), while anything lower than -127.5 will round to -128, and anything higher than 127.5 will round to +128 -- the extremes of the staircase function have half-quantization-step mappings, so the total effect is still 8-bit. This one has the advantage that both zero in and maxamp (positive or negative) give correct output values as well, but the disadvantage that one of the quantized steps is divided between the top and the bottom of the total range. Also, its graph is a reflection of that of the first function about a diagonal. In the third, one starts with the same math as the first, up to the floor function, which gives an effective range of -128 to 127. Then one simply divides by the original scalar, which just gives the mid-tread version of the function from the first formula (the first formula minus half the quantization step), with zeros-in-zeros out but one extra negative value than positive. Maybe sometime later I could post some pictures for two-bit audio. I'm sure there are plenty on the web. There's also the question of whether, even for a bit-crushing effect, one would add dither. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] list operation
Try the attached (threw together using list-abs) -- right inlet is the value (12 in your example) and left inlet is the list of floats; I think this follows established list-abs syntax. It's possible that I overlooked a list-abs that already does this, and there is probably a step or two you could skip. You might get poor results if the list is a bang or contains symbols. Matt Hello everyone, I would like to compare all the values in a list with a value of input and then decide which is the closest value and replace that value closer to the amount of input. For example, I have a list 2, 10, 35 and have an input value of 12 I would like the list as output 2, 12, 35. I'm almost getting, but the patch is so ugly that I will not show here, i'm sure there is a more elegant solution. Does anyone have an idea? tnx ;) -- next part -- An HTML attachment was scrubbed... URL: http://lists.puredata.info/pipermail/pd-list/attachments/20100427/ac720c09/attachment-0001.htm list-replace-closest.pd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] list operation
One thing to watch out for; if you get two items in the list that are equally as far as the test value, mine outputs one list with the value replacement at each appropriate index, while Jack's outputs several lists with the value replacement at only one index, but each replacement sequentially, if that makes any sense. So if the test value is 2.02, and the input list is 1 0 3 2 4 3 3 2 0 4, mine will output: 1 0 3 2.02 4 3 3 2.02 0 4 as one list, while Jack's gives two lists: 1 0 3 2.02 4 3 3 2 0 4 1 0 3 2 4 3 3 2.02 0 4 Matt On Tue, Apr 27, 2010 at 8:16 PM, Jack j...@rybn.org wrote: An alternative. Also full pure-pd. ++ Jack Le mardi 27 avril 2010 à 18:49 -0400, Matt Barber a écrit : Try the attached (threw together using list-abs) -- right inlet is the value (12 in your example) and left inlet is the list of floats; I think this follows established list-abs syntax. It's possible that I overlooked a list-abs that already does this, and there is probably a step or two you could skip. You might get poor results if the list is a bang or contains symbols. Matt Hello everyone, I would like to compare all the values in a list with a value of input and then decide which is the closest value and replace that value closer to the amount of input. For example, I have a list 2, 10, 35 and have an input value of 12 I would like the list as output 2, 12, 35. I'm almost getting, but the patch is so ugly that I will not show here, i'm sure there is a more elegant solution. Does anyone have an idea? tnx ;) -- next part -- An HTML attachment was scrubbed... URL: http://lists.puredata.info/pipermail/pd-list/attachments/20100427/ac720c09/attachment-0001.htm ___ 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] list operation
Ha ha, mine had a hilarious and totally unnecessary extra [list-map]. That's what happens when you work hastily... how embarrassing; oh well. MB On Tue, Apr 27, 2010 at 9:13 PM, Jack j...@rybn.org wrote: True, so now it should be OK (patch attached). I didn't think of this eventuality. ++ Jack Le mardi 27 avril 2010 à 20:50 -0400, Matt Barber a écrit : One thing to watch out for; if you get two items in the list that are equally as far as the test value, mine outputs one list with the value replacement at each appropriate index, while Jack's outputs several lists with the value replacement at only one index, but each replacement sequentially, if that makes any sense. So if the test value is 2.02, and the input list is 1 0 3 2 4 3 3 2 0 4, mine will output: 1 0 3 2.02 4 3 3 2.02 0 4 as one list, while Jack's gives two lists: 1 0 3 2.02 4 3 3 2 0 4 1 0 3 2 4 3 3 2.02 0 4 Matt On Tue, Apr 27, 2010 at 8:16 PM, Jack j...@rybn.org wrote: An alternative. Also full pure-pd. ++ Jack Le mardi 27 avril 2010 à 18:49 -0400, Matt Barber a écrit : Try the attached (threw together using list-abs) -- right inlet is the value (12 in your example) and left inlet is the list of floats; I think this follows established list-abs syntax. It's possible that I overlooked a list-abs that already does this, and there is probably a step or two you could skip. You might get poor results if the list is a bang or contains symbols. Matt Hello everyone, I would like to compare all the values in a list with a value of input and then decide which is the closest value and replace that value closer to the amount of input. For example, I have a list 2, 10, 35 and have an input value of 12 I would like the list as output 2, 12, 35. I'm almost getting, but the patch is so ugly that I will not show here, i'm sure there is a more elegant solution. Does anyone have an idea? tnx ;) -- next part -- An HTML attachment was scrubbed... URL: http://lists.puredata.info/pipermail/pd-list/attachments/20100427/ac720c09/attachment-0001.htm ___ 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
[PD] table abstractions
Hello list, For a while there had been talk about starting a vanilla-only table-abstraction collection in the spirit of list-abs and the iem_tab objects. This could be useful both for manipulation of or calculations using table data and for populating tables with desired data (in the manner of the csound GEN routines). I'd love to start it, but I don't know if I have enough Pd cred yet to be in charge of it. There are a few problems I'd like input on: 1) Naming -- would it be worth it to have different prefixes for objects which manipulated data, e.g. [table-reverse], and objects which populated tables, e.g. [tabwrite-blackman]? 2) Input-Output -- for the ones which manipulate data, should that generally happen in place unless a destination table is provided -- [table-qsort foo] sorts table values in table named foo and writes results back to foo, while [table-qsort foo bar] would sort foo's values and write them into bar? 3) In general I'm assuming that the objects which populate tables should simply write to a table, not internally provide the table to be written to. For instance, I'm thinking a [tabwrite-hann foo] which writes a hann window into foo would be more useful than a [table-hann foo] which internally instantiated a table called foo AND wrote a hann window to it, and responded to messages like resize with a larger or smaller hann window (I think accessing the table from without might be too buggy for this to be worth it). 4) Interpolation -- I'm also assuming that anything which would write a table that would usually be read by [tabread4~] or [tabosc4~] should write the guard points for proper interpolation by default. I've attached an example [tabwrite-chebyshev], which writes a weighted sum of chebyshev polynomials of the first kind to a table, probably for use with waveshaping, as an example of what I'm thinking of, and of a few options members of such a collection might have. (Incidentally, it might be a good idea to abbreviate this particular one to cheb or cheby due to the many transliterations, or even something like chebsum to name it like the sinesum or cosinesum array methods.) My thought is that many of us have already been making and using abstractions like these, and I think it would be worth it to collect them in a vanilla library for general use. Matt tabwrite-chebyshev.pd Description: Binary data tabwrite-chebyshev-help.pd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Smooth looping
On Sat, Apr 24, 2010 at 11:32:52AM +0200, Roman Haefeli wrote: The fact, that old Pd rabbits like you also have questions not only answers, is comforting. (even if they turn out to be not real questions ;-) The more you learn, the more questions turn up. :) Anyway back to the looping: With the fix, I can smoothly loop sine-waves now, but it still is pretty hard to get good looppoints for samples. Here's an example soundfile: http://footils.org/snd/23.wav With loopstart for example at sample 2912 and loopend at 5402, this looks pretty even in the array overlay, but if you listen to it, you can still hear a nasty rumble. I wonder, how to get rid of this ... I don't do very much looping, but if intuition serves I think you need to find loop points that share both the same value and the same first derivative (if your source is more or less periodic you can think of this as looping several sine waves and then mixing the results, and though I haven't thought it through it seems like the value and derivative would match best in places where the phase is similar for each constituent at the loop points). When I've tried to do looping, I've found it a little easier to find peaks with similar values, because I know that the derivative is the same at those peaks, while it's much harder to estimate the rate of change on zero-crossings. Anyway, for the sample you posted the best loop-point I could find was 2931-6153. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sourceforge access of the evil!
On Fri, 23 Apr 2010, Hans-Christoph Steiner wrote: As an American, I am required to fear what might happen if the rouge states got a hold of Pd. http://en.wikipedia.org/wiki/Rouge_%28cosmetics%29 rouge is pronounced with a long oo and soft g rogue is pronounced with a long oh and hard g (but in french the latter is more like : rug states) I thought he was making another joke, like the access/axis one. The red states here are the ones that vote republican. MB ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Smooth looping
Hi, not related to the thread on smoother audio in Pd, I am struggling with doing a smooth loop player for data stored in tables. One building block for this is attached: It is a simple tabread4~ lookup that should loop over a configurable section of a table and play it back with various frequencies. As you'll easily see, I use a [phasor~] | [*~ loopsize] | [+~ loopstart] | [tabread4~ table] idiom here. Now I would like to avoid enveloping the rewind sections, so I built an elaborate mechanism to set the loop points as good as possible by hand. Test sections let you load a sample or try to find the smooth loop points inside of a sine-wave table graphically. Now my problem is, that even when I have found a nice and smooth sounding loop section, as soon as I start to change the frequency played (with the pd transpose things), the sound gets very distorted. I'm puzzled: Shouldn't the tabread4~ interpolate correctly in this case? Any help or explanation is appreciated. (Except anything involving crossfades: I know I could do that and I guess I also know how.) Shouldn't you be multiplying the output of [pd transpose]-[lop~] with output of [r $0-loopfr]-[vline~] to change the frequency of the phasor, as opposed to multiplying the transpose stuff with the output of the phasor itself? In the latter case aren't you just expanding the output of the phasor to a different point in the file that is no longer necessarily loopable? Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] nusmuk_audio WAS: Max Smoother Audio than Pd?
Date: Wed, 21 Apr 2010 15:28:31 +0300 From: Jo?o Pais jmmmp...@googlemail.com Subject: Re: [PD] nusmuk_audio WAS: Max Smoother Audio than Pd? Cc: pd-list pd-list@iem.at Message-ID: op.vbik1qu2vpc...@jmmmp-thinkpad.fritz.box Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes So maybe you need and want a shitty clarinet to achieve the objective you have, maybe you need a quite expensive one. Nevertheless, the point is what you do with it. The clarinetist of one chamber orchestra I've wrote for had to use a 'C' clarinette that sounded like shit to play all the notes, instead of her cool but expensive B flat, the result is that I don't liked the sound she had. (If you want to compare I can send you the files) Richard Barret has a couple of interesting pieces for C clarinet (look for a cd with Carl Rossman). these pieces wouldn't sound as good in a B or A clarinets, because it would loose the hard edge of the rhythms/melodic contours. so, I say Richard Barret's pieces would sound like shit on a B clarinet. probably your's sounds like shit on a C clarinet. both clarinets can sound good - only the pieces they play can make them sound shit. Conclusion: don't blame the clarinets, stop giving them wrong pieces. Don't assume that one clarinet is worthless because he's being given the right material to play with. Ha ha, not to mention the proliferation of wonderful period-instrument ensembles that use 18th- and 19th-century replicas. Some of those musicians are really, really good -- the C clarinets sound just fine in the context of Beethoven and Berlioz. One would probably not want to play the Rite of Spring solo on an 18th-century bassoon, though. In music, and I think I would argue art in general, context is key. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] phasor~ and osc~ right inlet: exact timing
Thanks a lot for your explanations! On Sun, 2010-04-18 at 22:14 -0400, Matt Barber wrote: For this reason I almost always use an 8192-point [table] and [tabread4~] if I need more accurate sinusoids; By using 'sinesum' messages to [table]s? I can't think of another way to have access to more precise sinusoids in Pd, or is there any? Yes, either that (which seems to use the math.h sin or cos functions), or an [until] + [sin] + [tabwrite] routine. The former is easier, obviously, and also adds the three guard points automatically (it also seems to use the same precision of PI=3.14159 that you can get with floats in Pd patches). If you want the code, look for the function garray_dofo in g_array.c Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Send and receive execution order was Re: Zen Garden, re-implementing the wheel in C++?
Hi, On Sun, Apr 18, 2010 at 01:07:21PM +0200, Matteo Sisti Sette wrote: Frank Barknecht escribi?: *If* order matters to you (it may not always do) you can still use the subpatch approach with dummy inlet~/outlet~ objects. That's the part I don't understand. I mean I can't figure out the trick. I can easily imagine (and actually tried) how to patch things to force the desired order, but then again, I see myself obliged to do the wired connections that the [s~]/[r~]s were meant to avoid. May you please make an example of the technique? I would be so grateful. Attached is a very stupid example, which should show what I mean: Here various abstractions are layed out in a way, that they execute in order. Only one connection is used for order forcing, but still many s~/r~ are active, all properly ordered. Real life examples may not be so easy to sort, of course. Here's a relatively simple real-life example I posted a couple weeks ago: http://lists.puredata.info/pipermail/pd-list/2010-04/077392.html In this example I had an algebra problem that was complex enough that it would have been way too messy to draw wires for each term, so instead I named the terms and sent them via send~/receive~. However, because it was algebraic and not just an fx patch (where latency may or may not have mattered as much), I had to force execution order. It's really useful in cases where you have 10 send~s in one subpatch, because you can force order with just one connection -- sometimes a lot cleaner than 10 wires, especially when those wires would have gone to several different places. Matt PS -- I think my example has one unnecessary dummy outlet~/inlet~ pair, but I was being paranoid. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] phasor~ and osc~ right inlet: exact timing
Coming up again with the 'smoother' topic: Is [phasor~]-[cos~ ] precision-wise and interpolation-wise the same as an [osc~]? If not, which has less error and why? I think each one is 512-point linear interpolated. m_pd.h: #define LOGCOSTABSIZE 9 #define COSTABSIZE (1LOGCOSTABSIZE) This would give you 512 points. The code for both osc~ and cos~ have: *out++ = f1 + frac * (f2 - f1); Which, if the mnemonically named frac variable is just the fractional part of the index between f1 and f2, is a simple linear interpolation between the two points. For this reason I almost always use an 8192-point [table] and [tabread4~] if I need more accurate sinusoids; I've gotten pretty severe errors especially in cases where I need to divide a signal by the output of a cosine oscillator near 90-degrees phase (near the zero-crossing), and even more especially where the numerator is also near zero, just using [cos~], presumably both because the values from the oscillator output are near zero and because the function is changing at the greatest rate there. IIRC SuperCollider's SinOsc uses an 8192-point table with linear interpolation, and Phasor+BufRd you specify the table size and the type of interpolation (the cubic is the same as the Hermite one in [tabread4c~]). In csound's oscil* or phasor+table* opcodes you specify the table size (power of 2) and the type of interpolation (the cubic is identical to the Lagrange one in Pd). Someone please correct me if I'm mistaken. MB ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] nusmuk_audio WAS: Max Smoother Audio than Pd
Matteo Sisti Sette a ?crit : Frank wrote: It's not so much the tool, as it is the skills that makes music sound good. That is true for really good tools. Needless to say that Pd is one of them. sorry, I might going to be rude, but I've never heard some music completely made with PureData that really sound good. they are alway little experiments, or false reproductions of things we know and without the sound. like last time someone posted something that sounded like 'psychic warriors of gaia', but honnestly i'd prefer the original. The skill to make music with pd is about rewriting everything, at the end it's not really the skill of a musician, for example in concrete music, who is the musician, Pierre Schaeffer, or Pierre Henry? Pierre Schaeffer has demonstrated that he is a very skilled music scientist, but he didn't even made a shit that we could hear like a composition. pd is just a tool for learning dsp, there is no such project that show how pd is cool to make people moving on the dance floor. I might also be rude, here, but: http://en.wikipedia.org/wiki/Proof_by_example http://en.wikipedia.org/wiki/Fallacy_of_the_undistributed_middle (even if your premises were true) http://en.wikipedia.org/wiki/Argument_from_ignorance#Argument_from_personal_incredulity Etc. Also, there are plenty of counterexamples to your last premise, if you believe you can do the same things soundwise in Pd that you can in Max/MSP (e.g. plenty of people dance to Radiohead). I think maybe your feelings are more about the musical taste of musicians who use Pd than the technical possibilities of Pd. There are different social contours associated with all the various sound-producing softwares which say very little at all about the softwares themselves. (sorry to continue this thread) Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] phasor~ and osc~ right inlet: signal?
hi all thanks for your responses. Yes, the idea is to be able to slightly modify phasors~ phase to use it as an index to read a table. those ideas should work! PS -- E08.phase.mod.pd from the tutorial. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] [gbuzz~] -- band-limited pulse train
As a followup to last week's post, I put together an abstraction that works like csound's gbuzz opcode. Quite a bit more cpu-hungry... could maybe do with fewer options. If anyone has any efficiency ideas I'd welcome them -- the algebra is convoluted -- something using [expr~] would make things work better maybe. I did use [expr~] for the one audio pow operation to make this mostly compatible. Also uses [abs~]. Matt gbuzz~.pd Description: Binary data gbuzz~-test.pd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Parallel Circuit
Hello list, I wanted to share a recent piece with you: http://ecmc.rochester.edu/mbarb/web/music.php?filter=chrono#parallel_circuit It's for saxophone quartet and Pd -- all sounds in the piece come from the sax quartet directly, from processing the saxophone sounds, or from synthesis. The piece is in four broad movements, each in four distinct sub-sections (16 total). I use four different equal temperaments in the piece as well: 12 per 2:1 19 per 3:1 24 per 2:1 14 per 3:2 (one of each per broad movement). If you listen, I hope you enjoy. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [buzz~] -- bandlimited pulse train
I screwed up one of the comments -- the patch is right though; here's a replacement that fixes the formula (I think). MB On Thu, Apr 1, 2010 at 4:22 PM, Matt Barber brbrof...@gmail.com wrote: Since we've been talking about bandlimited signals, attached is an approach to an abstraction which can be used like the csound opcode buzz -- I just threw it together today and would of course welcome any improvements. Matt buzz~.pd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] tabread4~ broken interpolation algorithm - was Re:, Max Smoother Audio than Pd?
Now regarding Matt's words: I have read that the Lagrange interpolators have better stopband attenuation and Hermites have flatter passband response, but I'm not sure this is true Is it possible that it is exactly viceversa? I think it probably is exactly vice-versa -- I was quoting people in other forums who said so, so, you know -- who knows if it's true. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] tabread4~ broken interpolation algorithm - was Re:, Max Smoother Audio than Pd?
Yes, as far as I know it's identical -- when you do one of these interpolations with four points, you can either think of it in terms of a cubic polynomial formula involving those four points, or in terms of the sum of four scaled basis functions - the latter seems to me intuitively equivalent to direct convolution of an impulse response centered on the four points, and scaled to each. It will be limited by the quantization of the index, so in that sense it might not be linear.. MB On Tue, Mar 30, 2010 at 6:45 AM, Matteo Sisti Sette matteosistise...@gmail.com wrote: Is it really possible to express a cubic interpolator (such as Lagrange or Hermite, i.e. such as tabread4 or tabread4c) in terms of impulse response? Is it equivalent to a convolution? That is to ask: is it linear??? Or is that an approximation? -- Matteo Sisti Sette matteosistise...@gmail.com http://www.matteosistisette.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] tabread4~ broken interpolation algorithm - was Re:, Max Smoother Audio than Pd?
On Tue, Mar 30, 2010 at 9:52 AM, Matteo Sisti Sette matteosistise...@gmail.com wrote: Matt Barber escribió: Yes, as far as I know it's identical -- when you do one of these interpolations with four points, you can either think of it in terms of a cubic polynomial formula involving those four points, or in terms of the sum of four scaled basis functions - the latter seems to me intuitively equivalent to direct convolution of an impulse response centered on the four points, and scaled to each. It will be limited by the quantization of the index, so in that sense it might not be linear.. Hmm, by linear I mean that the interpolated version of the sum of any two discrete signals is equal to the sum of the interpotated versions of each one. It shouldn't be difficult to tell whether this is true or not by looking at the formulas but I'm too lazy right now :P Right, I think it should absolutely be linear in that sense, provided you used exactly the same index for both processes and ignored any rounding errors from adding samples. In math it should be linear, but I'm not 100% sure about what quantization of index or sample does to it (we often don't worry so much about it anyway). ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Birds use stars - diatonic
What are some ways of telling each of the synths to round to the nearest note in a diatonic scale? think of all the separation points between what is rounded to one note, and what is rounded to another note. for a standard Do major scale, if all your inputs are between 60 and 72, you can split with this : [moses 61]/[moses 63]/[moses 64.5]/[moses 66]/[moses 68]/[moses 70]/[moses 71.5] because those are the averages of any two consecutive notes of the scale. then you connect each left-outlet to the note that you want that range of values to become. there are further tricks for supporting multiple octaves without having to make a longer chain of [moses]. as a shortcut to make many [moses], there is [range] : [range 61 63 64.5 66 68 70 71.5] in the GridFlow library. You can also take your values mod 12 and use those numbers to read indices in a 12-member table you've populated with a mapping onto your favorite scale. If your values are floats you might round them first. You can also keep track of the whole-number quotient of your value divided by 12 so that you can get your specific octave back as well -- this gives you the equivalent of an octave-pitch-class notation, like the kind you might find in csound. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] tabread4~ broken interpolation algorithm - was Re: Max Smoother Audio than Pd?
I checked it out (not read the _whole_ thread to the end) but, In what way can the current tabread4~ interpolation, which is discontinuous even in its 1st derivative, be superior to true cubic interpolation? Even at transpositions near to zero, I can't see what's the advantage, nor what it is supposed to minimize. both are truly cubic interpolations. IIRC, one kind of cubic interpolation is designed to go through all four points, and the other kind is designed to be pieced with other cubic interpolations, and Miller confused the two and left the bug there. Miller's is a true implementation of the former -- his is a Lagrange interpolator which goes through all points -- it's algebraically identical to the cubic interpolator in csound, and so it should have a similar sound as any of the table-reading opcodes in csound that also employ cubic interpolation. The latter is an Hermite interpolator which uses the outside points to approximate the first derivative -- the resulting curve only passes through the middle two points, but doesn't go through the outside two; this ensures that as it's pieced together the first derivative will be continuous at the junctions. It's algebraically identical to the cubic interpolator in supercollider. They're two different approaches -- each has its own frequency response, but both are true cubics. If you want to match all four points AND the first derivatives, you have to use a 5th-order polynomial. The formulas are easily derivable using the Gaussian method, and it's easy to implement all these as a library of functions that can be accessed by the relevant objects, where the user can choose which type of interpolation he/she wants to use. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Birds use stars - diatonic
Yes, this is all true. What I like about a tabread is the possibility for quickly applying many different kinds of mappings, diatonic or otherwise -- if you assume a chromatic input (rather than a fully microtonal input -- ints instead of floats) this becomes quite a bit easier. MB On Mon, Mar 29, 2010 at 10:29 AM, Mathieu Bouchard ma...@artengine.ca wrote: You can also take your values mod 12 and use those numbers to read indices in a 12-member table you've populated with a mapping onto your favorite scale. If your values are floats you might round them first. You can also keep track of the whole-number quotient of your value divided by 12 so that you can get your specific octave back as well -- this gives you the equivalent of an octave-pitch-class notation, like the kind you might find in csound. your method does not take into account that the mapping to the closest note has two different widths, 2 halftones for notes not next to a semitone interval, 1.5 halftone for those that are (Mi,Fa,Si,Do). what I was alluding to, for multiple octaves, is to use something like [wrap], so that you can use a chain of [moses] made for one octave, removing the octave number before going into [moses] and putting back right after. but since all ranges are multiples of a quartertone, one could multiply the midi note by 2, round, then go through a [tabread]. if you don't convert to quartertones, the rounding to the closest integer will conflict with the goal of rounding to the closest note, so you won't be able to get the closest note. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] tabread4~ broken interpolation algorithm - was Re: Max Smoother Audio than Pd?
of [tabread4~] vs. the [tabread4c~] http://lists.puredata.info/pipermail/pd-list/2008-06/063408.html (look at the graph) We came up with lots of 4-point schemes -- you can come up with a 7th-degree polynomial that matches all four points, both first derivatives and both second derivatives -- each has a different frequency response. I think we even tried out a cosine-segment interpolator that was derived from zero-padding the frequency domain of the fft of the four points. I haven't studied those things in school, so please forgive, if I am asking things with completely wrong assumptions. I am just trying to understand why [tabread4~] is good for what it is. I haven't studied them in school either which is why I worry about the above explanation. I think [tabread4~] is good for what it is for a couple of reasons, neither of them particularly compelling: 1) It's better than linear interpolation, and has wide use in other computer-music applications like csound -- people are very used to how it behaves. 2) It's similar to the alternative being discussed, but with a different sound; not necessarily worse for all sounds. I have read that the Lagrange interpolators have better stopband attenuation and Hermites have flatter passband response, but I'm not sure this is true -- anyway, google hermite vs. lagrange. Matt Roman On Mon, 2010-03-29 at 16:33 -0400, Matt Barber wrote: Miller's is a true implementation of the former -- his is a Lagrange interpolator which goes through all points -- it's algebraically identical to the cubic interpolator in csound, and so it should have a similar sound as any of the table-reading opcodes in csound that also employ cubic interpolation. The latter is an Hermite interpolator which uses the outside points to approximate the first derivative -- the resulting curve only passes through the middle two points, but doesn't go through the outside two; this ensures that as it's pieced together the first derivative will be continuous at the junctions. It's algebraically identical to the cubic interpolator in supercollider. They're two different approaches -- each has its own frequency response, but both are true cubics. If you want to match all four points AND the first derivatives, you have to use a 5th-order polynomial. The formulas are easily derivable using the Gaussian method, and it's easy to implement all these as a library of functions that can be accessed by the relevant objects, where the user can choose which type of interpolation he/she wants to use. Matt tabread4-impulse-response.pd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Max Smoother Audio than Pd?
Alexandre Porres wrote: I feel Max produce a smoother audio than Pd. Didit Well, if you use [tabread4~] or any of the many other Pd objects that use the same broken interpolation algorithm (copy/paste programming), you get horrible noise. If you use [tabread4] to interpolate graphical parameters for animations, the discontinuities in the derivatives are really obvious. Pd's cubic interpolator is a standard one (not the only standard one) -- it's the same Lagrange interpolator as the one used in csound. [tabread4c~] or whatever it is was an attempt to bring in the one used in supercollider, which is an Hermite cubic interpolator. I haven't tried to figure out what max uses, but it wouldn't be too hard. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Reproducing the THX deep note in Pd
Table sizes in Csound are user-defined. You can also use user-defined tables in Pd with [tabosc4~]. I think what may be a little more important for the differences in sound is the fact that csound and Pd use Lagrange interpolators and supercollider uses an Hermite one for the cubic interpolation within oscillators. Matt Pd's oscillator wave tables are 512 samples. Supercollider uses 8192 - not sure what CSound uses. The efficiency of the SC code allows for large sample tables and bigger FFTs, which certainly help make a 'smoother' sound. It would be interesting to hear what happens with 16x larger tables in Pd. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Weird [delread~] behavior under -nogui
Are we sure this is a problem with [delread~]? There's a related bug where if you open a patch which has delays at one sample rate, if you then change the sample rate in the preferences it won't reallocate the delay buffers, so if you increase the sample rate, you're left with shorter delay lines (they're just as long in samples but shorter in milliseconds). When it happens it feels like a [delread~] problem since that's what you're controlling, but really it's in the implementation of the delay buffer. This may have been fixed in recent versions -- I have been keeping at 0.40 for a while now, so I don't know for sure. Matt Hey Flo, IOhannes accused me of making this up when I posted it a week or so ago ;-) Thanks for posting a documented example. Yes it does seem like voodoo doesn't it? D. On 3/27/10 3:13 PM, Florian Hollerweger wrote: Dear list, When starting Pd with the -nogui flag, [delread~] seems to ignore its float input (specifying the delay time in ms) and instead produce sounds which resemble a [delwrite~]/[delread~] loop at very short (one block of audio?) delay times. Attached is a minimal example. (Attention, this will play straight to your soundcard at -20 dB for easy testing with -nogui!). To try, please start Pd first with and then without GUI. I have observed this behaviour with Pd 0.41.4 under Debian GNU/Linux. Anyone else who ran into trouble with this or might know what's going on? best, flo.H === BEGIN MINIMAL EXAMPLE === #N canvas 2 0 568 517 10; #X obj 132 359 dac~; #X obj 139 118 loadbang; #X obj 132 153 metro 1000; #X obj -23 386 loadbang; #X msg -23 441 \; pd dsp 1; #X obj -23 413 del 1000; #X obj 53 151 osc~ 220; #X obj 61 251 *~; #X msg 80 200 1 \, 0 100; #X obj 80 225 line~; #X text 330 478 Florian Hollerweger \, 2010; #X obj 132 330 *~; #X obj 205 294 dbtorms; #X obj 205 246 loadbang; #X msg 205 270 80; #X obj 162 220 delread~ line 350; #X obj -13 332 delwrite~ line 580; #X text 45 410- This [del 1000] is required due to another -nogui bug (audio will not work under -nogui without it); #X text -11 88 Tested with Pd 0.41.4 under Debian GNU/Linux; #X text 249 272 Master volume; #X obj 161 332 *~; #X msg 164 193 500; #X text -10 8 -nogui bug: This patch creates a test signal on the left channel once a second \, which is delayed through [delwrite~] and [delread~] and then repeated on the right channel 500ms later. But when started with -nogui \, the delay time of 500ms seems to be ignored.; #X connect 1 0 2 0; #X connect 1 0 21 0; #X connect 2 0 8 0; #X connect 3 0 5 0; #X connect 5 0 4 0; #X connect 6 0 7 0; #X connect 7 0 16 0; #X connect 7 0 11 0; #X connect 8 0 9 0; #X connect 9 0 7 1; #X connect 11 0 0 0; #X connect 12 0 11 1; #X connect 12 0 20 1; #X connect 13 0 14 0; #X connect 14 0 12 0; #X connect 15 0 20 0; #X connect 20 0 0 1; #X connect 21 0 15 0; === END MINIMAL EXAMPLE === ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- ::: derek holzer ::: http://macumbista.net ::: ---Oblique Strategy # 112: Magnify the most difficult details ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] expr size() refuses some array names
Here's the proper way to do it: [symbol $0-foo] | [expr size($s1)] substitute anything that outputs the symbol (with the symbol selector) that you want -- [makefilename], etc. Matt Last option would be to try using [sprintf], [makefilename] or similar to create the array name, and send to [expr size($1)] . Maybe Prost! D. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] expr size() refuses some array names
The problem is not specific to dollar signs: the problem is that expr won't accept a name (for the array in this case) that starts with a number, or that contains an aritmetical operation sign. Which, besides not allowing for names that are legal in Pd, seems like an error in the parsing process, because it seems it applies the same rules inside quotation marks that it would apply without quotes. I think the best thing is to tell [expr] to expect a symbol in its first inlet (the name of the array), and then create the symbol by other means. This more in keeping with the normal usage of [expr] and friends anyway, I think. [symbol $0-foo] | [expr size($s1)] has always worked for me. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] expr size() refuses some array names
http://crca.ucsd.edu/~syadegar/expr.html specifically: -- Tables and variables can be accessed the same way one dimensional arrays are accessed in C; for example, valx + 10 will be evaluated to the value of variable 'valx' + 10 (variables have to be defined using the 'value' object) and tabname[5] will be evaluated to be the 5th element of table tabname. The name of the table can be a variable as well; for example $s2[5] will be evaluated to be the 5 element of the array whose symbol has been passed in inlet 2. --- On Sat, Mar 27, 2010 at 4:55 PM, colet.patr...@free.fr wrote: oh, didn't know all of this, where it's documented? just [bang--[list prepend $0foo]--[expr size($s1)] did the trick thanks and sorry for the misleading. Here's the proper way to do it: [symbol $0-foo] | [expr size($s1)] substitute anything that outputs the symbol (with the symbol selector) that you want -- [makefilename], etc. Matt Last option would be to try using [sprintf], [makefilename] or similar to create the array name, and send to [expr size($1)] . Maybe Prost! D. ___ 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] -rt w/ pd-extended on OS X
One more thing (sorry if this is stating the obvious) -- it's a great idea to make aggressive use of [switch~] where possible, so that modules that aren't currently being used in the patch don't contribute to cpu use. Matt Hi Dan, OS war wasn't my intention. Finding out if the -rt flag on OSX was. FWIW, I got very fed up with being a systems administrator instead of making instruments and sounds, and haven't booted the Gentoo partition in at least two years now... D. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] A better pitch shifter?
I've used this pitch shifter quite a lot for a number of different things -- how you use it seems to depend completely on context. For instance, if you're shifting mostly sustained sounds (so that attacks aren't so present), you can use a larger window size, which reduces some of the modulation artifacts you get when you use a lower size. You need the lower size for fast things, or things with strong attacks. I once experimented with trying to get the window to match exactly period boundaries of the incoming sound (to reduce the modulation completely), but it really only works with electronic sounds where you can be absolutely sure of the frequency. I have had luck in some rare cases mixing the output of two pitchshifters set to the same transposition but different window sizes -- again, no difference in latency, but it can help smooth things out if you're really aggressively pitchshifting something (like, by a perfect 12th), where presence isn't really something you're going to be able to attain anyway. I now keep several of them around with different settings for different contexts. Matt Hi all, I tried making a mult-delay pitch shifter once. It was no good for reducing latency, but it did slightly decrease the phenomenon of double attacks one sometimes gets - but also reduces the presence of the sound, not a tradeoff I liked in the end. I tried a bunch of other things over a period of months with no luck. cheers Miller On Wed, Mar 03, 2010 at 04:34:38PM +0100, Pierre Massat wrote: Hi! I have been using Miller Puckette's delay-based pitch-shifter (from the audio examples) for quite a while now, and i was wondering if it would be possible to improve it a bit. In particular i'd like to reduce the delay length to lower latency (i m using it in real time). Would adding more delay lines help me solve this problem? I must say that i never took the trouble to try and understand how this patch works, so i'm not sure where to start. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] No voltage-controlled lowpass filter?
Hi, Is vcf~ (which is bandpass) the only available type of signal-controlled (smoothly-changing) filter? Doesn't the voltage-controlled version of lop~ and hip~ exist? Is it for a mathematical reason? (i.e. impossibility to implement in a relatively simple way) Or is it because it is trivial to build it in PD? If so, how? And if not, how would you approximate it, that is create in PD something similar to a simple low-pass filter whose cutoff frequency is controlled by a signal? Attached are some abstractions I once threw together which should be quite similar to the user-friendly ones. Sorry for the very silly help patch -- I hope I haven't made any stupid mistakes. MB #N canvas 195 68 319 395 10; #X obj 38 34 inlet~; #X obj 124 34 inlet~; #X obj 38 253 rpole~; #X obj 195 57 samplerate~; #X obj 195 79 swap 1; #X obj 195 102 /; #X obj 195 34 loadbang; #X obj 124 119 *~ 0; #X obj 71 119 sig~ 1; #X obj 71 180 -~; #X obj 38 227 *~; #X obj 38 278 outlet~; #X obj 124 143 max~ 0; #X obj 124 164 min~ 1; #X obj 124 79 *~ 6.28318; #X connect 0 0 10 0; #X connect 1 0 14 0; #X connect 2 0 11 0; #X connect 3 0 4 0; #X connect 4 0 5 0; #X connect 4 1 5 1; #X connect 5 0 7 1; #X connect 6 0 3 0; #X connect 7 0 12 0; #X connect 8 0 9 0; #X connect 9 0 2 1; #X connect 10 0 2 0; #X connect 12 0 13 0; #X connect 13 0 9 1; #X connect 13 0 10 1; #X connect 14 0 7 0; #N canvas 104 392 337 344 10; #X obj 38 64 inlet~; #X obj 94 64 inlet~; #X obj 38 243 rpole~; #X obj 185 88 samplerate~; #X obj 185 109 swap 1; #X obj 185 132 /; #X obj 185 64 loadbang; #X obj 94 149 *~ 0; #X obj 38 292 outlet~; #X obj 38 268 rzero~ 1; #X obj 94 171 max~ -1; #X obj 94 193 min~ 0; #X obj 94 109 *~ -6.28318; #X obj 93 227 +~ 1; #X connect 0 0 2 0; #X connect 1 0 12 0; #X connect 2 0 9 0; #X connect 3 0 4 0; #X connect 4 0 5 0; #X connect 4 1 5 1; #X connect 5 0 7 1; #X connect 6 0 3 0; #X connect 7 0 10 0; #X connect 9 0 8 0; #X connect 10 0 11 0; #X connect 11 0 13 0; #X connect 12 0 7 0; #X connect 13 0 2 1; #N canvas 36 660 566 311 10; #X obj 145 169 -~; #X obj 281 165 -~; #X obj 132 43 noise~; #X obj 272 52 sig~; #X obj 182 110 lop~; #X obj 137 82 vcl~; #X obj 263 96 vch~; #X obj 305 93 hip~; #X floatatom 337 38 5 0 0 0 - - -; #X obj 159 213 print~; #X obj 277 224 print~; #X obj 195 178 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 330 179 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X text 381 37 - set cutoff; #X connect 0 0 9 0; #X connect 1 0 10 0; #X connect 2 0 5 0; #X connect 2 0 4 0; #X connect 2 0 6 0; #X connect 2 0 7 0; #X connect 3 0 5 1; #X connect 3 0 6 1; #X connect 4 0 0 1; #X connect 5 0 0 0; #X connect 6 0 1 0; #X connect 7 0 1 1; #X connect 8 0 3 0; #X connect 8 0 7 1; #X connect 8 0 4 1; #X connect 11 0 9 0; #X connect 12 0 10 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] peak amplitude in pd vanilla (was: [env~] vs [vsnapshot~]: which one is more cpu consuming?)
If you need to send a 0 at the beginning of each block, here are some interesting ways of doing it that just occurred to me: __ [sig~ -1] [block blocksize] | [rfft~] | [/~ blocksize] | [+~ 1] | ___ and the best: ___ [sig~ 1] [block~ blocksize] | [lrshift~ -1] | An [lrshift~ 1] will give you a 0 at the end of block. Attached is an abstraction which should output the signed peak of the current block as a signal. Optional creation argument for the size of the block you want to use, and the block size is also settable via the right inlet [set blocksize( If you don't want signed peak you can make this quite a bit more efficient by dropping in the patch from before. MB On Mon, Feb 15, 2010 at 7:29 PM, Matt Barber brbrof...@gmail.com wrote: hello im sorry i left the thread for some time now. thank you all very much for your replies. Your results are confirmed here too: the two methods with vsnapshot~ and writing-reading to a table are equally inefficient. Matt's suggestion --whilst much more efficient-- has a serious disadvantage: it seems that there is no way of reseting [max~ ] without losing some samples (which could include a peak). Generally, i had many confusing problems while testing that one. Has anyone else tried it?? I give up for now due to the lack of time if anyone has another idea, please share! :-) (By the way: there is another limitation i noticed in [bang~ ]: it won't go faster than 1 bang every 64 samples, even if the block size is set under that) Best would be to reset it with the result of subtracting a dirac delta from a constant signal of 1 (which should give a one-sample 0). Attached is a [dirac-delta~] abstraction -- it could be far more efficient for your purposes, but it's meant to work more or less like the [dirac~] object from zexy so it has a couple of extra goodies you probably don't need. I forgot what the [bang~] is supposed to do -- was it to reset the [max~] every block? In that case a tentative solution would be to set a phasor to run at exactly the frequency corresponding to the period of a block size, and divide it by itself. If the phase remains zero and you feed it nothing but powers of two, it should produce a 0 once per cycle (and thus once per block). There are more robust solutions, but this might work in a pinch. MB peak-sample~.pd Description: Binary data peak-sample~-help.pd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] peak amplitude in pd vanilla (was: [env~] vs [vsnapshot~]: which one is more cpu consuming?)
hello im sorry i left the thread for some time now. thank you all very much for your replies. Your results are confirmed here too: the two methods with vsnapshot~ and writing-reading to a table are equally inefficient. Matt's suggestion --whilst much more efficient-- has a serious disadvantage: it seems that there is no way of reseting [max~ ] without losing some samples (which could include a peak). Generally, i had many confusing problems while testing that one. Has anyone else tried it?? I give up for now due to the lack of time if anyone has another idea, please share! :-) (By the way: there is another limitation i noticed in [bang~ ]: it won't go faster than 1 bang every 64 samples, even if the block size is set under that) Best would be to reset it with the result of subtracting a dirac delta from a constant signal of 1 (which should give a one-sample 0). Attached is a [dirac-delta~] abstraction -- it could be far more efficient for your purposes, but it's meant to work more or less like the [dirac~] object from zexy so it has a couple of extra goodies you probably don't need. I forgot what the [bang~] is supposed to do -- was it to reset the [max~] every block? In that case a tentative solution would be to set a phasor to run at exactly the frequency corresponding to the period of a block size, and divide it by itself. If the phase remains zero and you feed it nothing but powers of two, it should produce a 0 once per cycle (and thus once per block). There are more robust solutions, but this might work in a pinch. MB dirac-delta~.pd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] peak amplitude in pd vanilla (was: [env~ ] vs [vsnapshot~ ]: which one is more cpu consuming?)
As I understand it (and hopefully i am not completely wrong..) you don't have to 'store' a list and 'then' read again it to find the max magnitude. It's as simple as the following: (some signal) *I* *I* [pd me...@samplerate] *I*/ [vsnapshot~ ] | [abs ] | [moses ]X[t f ] | [f ] I think I may have misunderstood your task earlier. In any case, you'll probably still do what you want more efficiently at the signal level: --- [inlet~] [block~ 1] | [abs~] [delread~ $0-compare 0] | / |/ [max~] |\ | \ | [delwrite~ $0-compare 1] | [outlet~] --- The [delread~] should be a one-sample delay, so you're just comparing the previous maximum with the current sample and outputting the larger of the two. Then on the outside you can poll that with snapshot~ periodically just like you did your float object above. If you need to reset it, I think you can just have the [delread~] feed into a [*~] with a [line~] that jumps from 1 to 0 and back to 1. Use [switch~ 1] instead of [block~ 1] if you want to be able to test the cpu load from that patch. I hope this works. I don't think that [env~] does what you want it to at all. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] shouldn't message boxes work as gui elements?
I don't know if this is already being addressed in the rewrite-gui version... I've always wondered why message boxes are not treated as gui elements, like number and symbol boxes, that is: - they do not graph on parent - they do not have a properties dialog with at least a send and receive symbol Is there some particular reason why it has been decided not to treat (or allow treating) message boxes as gui elements, or is it simply that it has never been felt as a priority to implement this feature? I mean, would it imply any drawback? It would make some things really difficult to have them GOP -- sometimes you need to use them for bookkeeping things that have little to do with making human-readable messages -- even simple things like if higher than five, send a 1, otherwise send dog, but if zero turn off pd dsp are easier to do with message boxes, but you don't want to see them on your graph because they have nothing to do with a patch user, and you don't want to have to hide them out of the GOP rectangle. A separate gui object would probably be the best bet... please don't make regular message boxes graph on parent. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [env~ ] vs [vsnapshot~ ]: which one is more cpu consuming?
It would be nice though, to know also on a theoretical level. Which one should be more expensive and (maybe) why. I was just taking a look at d_ctl.c from source. It looks like snapshot~ is cheapest because it's not trying to get any specific sample from the block. vsnapshot~ gets the logical time on every DSP tick and copies each passing block to memory. Then, upon receiving a bang, it gets the time elapsed since that last DSP tick. Based on that time, it makes an index into the copied block to bring up the exact sample that was flying by when you banged it (at least, as close as possible). So that's a clock call and a block copy every 1.45 ms with normal 64 sample block size, plus the arithmetic necessary to compute the index into the block. By using [block~ 1], you're increasing the number of clock calls, and the arithmetic for finding an index is kind of wasted since the block is only one sample long. Maybe it would be best to avoid [block~] and bang vsnapshot~ with a metro set to 1/44.1 ms. You'd at least be reducing the number of clock_getlogicaltime() calls. env~ is more or less just summing and squaring each block (very cheap), then calling a powtodb conversion function. You've got it set to process a block of 4096 samples every 2048 samples. So that's taking advantage of the more efficient block processing strategy. Also, you should know that the result of [env~] is something akin to a low-pass filter; the speed limiting from the original patch might be done more efficiently by squaring the signal and sending it through a (probably aggressive) low-pass filter before sending it to vsnapshot -- in that case it's possible that regular old snapshot with a larger [block~] size might work just as well, since you'll be sending a signal that doesn't change as quickly. You also need to take into account that doing message-level computations every sample might be fairly inefficient in general, and this is not something that [env~] is usually doing. Further, updating a vu gui every sample will probably be almost ridiculously inefficient -- try comparing the two setups with and without the vu connected (it may be that you have already taken care of this in the speed limiting and are not actually updating it every sample after all). Either way, it's always good to test efficiency with and without the guis, since the gui operations add an extra layer. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get the values of an array as a list
I don't know if this is relevant, but I thought that since it came up I would mention that you can get the size of an array with expr: [symbol arrayname( | [expr size($s1)] should do it. Matt My little participation :) A small modification of [list-tabdump] is 40% faster than the original (avoiding to send everytime the new list from [list append] in [list]). ++ Jack Le jeudi 21 janvier 2010 ? 13:53 +0100, Roman Haefeli a ?crit : Am 21.01.10 09:57 schrieb William Brent unter william.br...@gmail.com: But is there something in Pd-ext that does this? There must be, right? An external is wy faster for long arrays. An external will always be faster. However, the patching method still can be optimized a lot. [list-tabdump] copies the same data back and forth and the number-of-elemts/cputime ratio is not linear, but something like 'exponential' (please someone put here the correct term). Attached is a benchmark patch, that compares [tabdump], [list-tabdump] and a patched vanilla version, that has a linear ratio, which makes it a lot faster than [list-tabdump], especially with big arrays (though it is still 10 times slower than [tabdump]). Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Convolution / Impulse Response
I used to have a set of abstractions that did this. I threw it together on a whim, it wasn't all that efficient, and I haven't tested it in a couple of years... it would need a total revamp to be usable even for teaching because the constituent abstractions are not documented and not altogether straightforward. Anyway, I think you can copy the contents of an impulse-response array to several smaller arrays (the partitioning) using dynamic patching, then do fft-convolution with the incoming signal and the contents of the array (using [tabreceive~]), and then delay each separate signal by the appropriate amount (taking block delay into account) so that the aggregate produces the original impulse response convolved with the input. I think you might be able to get a bonus in efficiency if you do the partitioning into the following array sizes: 64 64 128 128 256 256 512 512 etc. Then you can avoid having more than a 64-sample-block delay overall, because the block delay associated with each set of larger arrays will be just enough to collect enough samples to compute the fft, do the mulitplication and ifft, and output the result. You might even be able to build in a buffer by doing: 64 32 32 64 64 128 128 256 256 512 512 etc. This should give extra time to compute the fft-mult-ifft I think I had built in an optional maximum fft size, so that at some point it would just continue to partition into, say, 8192-sample chunks. I had been thinking about doing the first block as a direct convolution for no overall delay, but I couldn't decide whether it would be worth it from the standpoint of efficiency... anyway, I couldn't get it to work without dropouts for a response of more than about 2 seconds long. Matt is it possible to do something vaguely similiar in vanilla pd? -- next part -- An HTML attachment was scrubbed... URL: http://lists.puredata.info/pipermail/pd-list/attachments/20100121/0a39cf0d/attachment-0001.htm ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] slightly off topic - interesting generative/recursive music inspiration
This is interesting, but unfortunately it isn't a correct analysis -- for it to be a real mobius strip it would need inversional symmetry, not symmetry in time -- the topology of this piece does not match that of a mobius strip (to visualize the topology of the music itself, you have to imagine it being written on a transparent strip). With an opaque strip, you can actually just write any music whatsoever -- this would have worked fine with no twists in the strip (and no music on the inside). Canon 1 a 2 from J. S. Bach as a M?bius strip http://strangepaths.com/canon-1-a-2/2009/01/18/en/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] slightly off topic - interesting generative/recursive music inspiration
Well, yes, but the crab-canon symmetry here has nothing to do with the mobius strip -- it still needed two playheads running in the opposite direction to accomplish the task, and it could be written on any (opaque) two-dimensional surface with the same parameters. I actually had two points: 1) You can put any piece on an opaque two-dimensional surface, including a mobius strip. In the case of the Bach piece the relevant contrapuntal thing is the retrograde symmetry, so the mobius strip adds nothing. 2) If you wanted an analogous piece where the mobius strip was actually relevant, you would need to craft the piece so that it was syntactically well-formed in inversion. Imagine it being written on a transparent mobius strip where the playhead plays the front and the back of each note at different times as it passes them -- the playhead will be upside down on one of the passes. As a bonus, if you could craft it with retrograde-inversional symmetry, you could use the two playheads running in opposite directions as in the video and make what is usually called a flip canon -- a piece that can be played by two players looking at the same music from opposite sides of a table. To put this another way -- imagine the Bach piece is written on a window. To play it correctly, you would need a player on each side of the glass. A mobius-strip piece with one playhead would sound like a piece followed by its inversion. With two playheads running in the opposite direction would have one of two properties depending on which side the playheads start, and in which orientation: 1) it would be the piece followed by its inversion in one voice accompanied by the retrograde inversion of the whole thing in the other voice (a flip canon), or 2) the piece followed by its inversion in one voice accompanied by the retrograde of the whole thing (a crab canon). If it's played with the same timbre, the Bach piece (a crab canon) sounds like a piece in two voices followed by its retrograde. A piece with a real mobius strip topology with two playheads running in opposite directions like the video would sound like either a flip canon or a crab canon followed by its inversion. Matt On Sun, Jan 17, 2010 at 6:51 PM, Mario Mora mare...@gmail.com wrote: if you check that video with the volume on, you will hear that the intervalic relationships between the notes are perfect, this means that the beginning works perfectly in conjunction with the end, and that means that what can be melody, can also be accompaniment, so you can do any inversion of the music and it will work as a musical piece because it is perfectly symmetrical, to put any music whatsoever, in your words, does not guarantee a musical result, and in fact, does not guarantee music in a coherent sense, and obviously, does not garantee any symmetry at all. In this example, the musical result is accomplished by laws of complex intervalic relationships between the notes, called counterpoint, and Bach was a master on that. It is about what you hear, not about what you see, the score is just a graphic way of to write relations of time and frequency of a music so that can be read and performed by a human being. 2010/1/17 Matt Barber brbrof...@gmail.com This is interesting, but unfortunately it isn't a correct analysis -- for it to be a real mobius strip it would need inversional symmetry, not symmetry in time -- the topology of this piece does not match that of a mobius strip (to visualize the topology of the music itself, you have to imagine it being written on a transparent strip). With an opaque strip, you can actually just write any music whatsoever -- this would have worked fine with no twists in the strip (and no music on the inside). Canon 1 a 2 from J. S. Bach as a M?bius strip http://strangepaths.com/canon-1-a-2/2009/01/18/en/ ___ 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
[PD] Fedora 12 + gnome DPI + tcl/tk 8.5
Hello, I'm working in Pd extended using the planetccrma package, on Fedora 12, comparing behavior on two systems. I found on one system all the iemgui fonts appeared correct, but the normal object fonts appeared too small (which is the opposite of usual; normally the object fonts are correct and the iemgui fonts are too large), but only when logged in using GNOME -- fluxbox made things bad again. Also on a machine with the identical setup but a different monitor, even in gnome the iemguis appeared too large again. The only two differences between my machines were the X11 DPI setting (xdpyinfo | grep resolution gave me 75 on one and 96 on the other) and the gnome DPI settings under System-Preferences-Appearance-Fonts-Details-Resolution . As it turns out, if the gnome one is set to 72, the patches look the same as on other operating systems, except the object fonts are too small (I could fix this by editing the sizelist hack in pd.tk back to normal). Also, in fluxbox, the only way to get iemguis to look correct is if I run /usr/libexec/gnome-settings-daemon. I don't know tcl/tk well enough to know what all this means, but it seems the X11 DPI is meaningless to Pd, at least on my systems; I can make patches look normal (but fonts in other applications way too small) by setting the gnome DPI to 72, and resetting the sizelist hack. I hope this is a little useful. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Vanilla [list-s2l] prototype
SplitTheAtoms = 16ms VanillaRulz = 27ms Teddy = 23ms 1234 = 140ms PdIsGreat = 30ms using tclpd: under 0.05 ms for any of those. size of the external: about 260 bytes. and no symbol-table pollution, no memory leak. I think this might underline how useful it would be for those of us who use vanilla Pd to have some symbol manipulation tools in vanilla, although I'm not convinced that I'm doing the symbol2list in the best way for vanilla either (I used to think it couldn't be done at all). Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Vanilla [list-s2l] prototype
On Thu, Nov 19, 2009 at 7:44 PM, Mathieu Bouchard ma...@artengine.ca wrote: On Thu, 19 Nov 2009, Matt Barber wrote: I think this might underline how useful it would be for those of us who use vanilla Pd to have some symbol manipulation tools in vanilla, It's useless to underline it more than it's been underlined before. Just stop using vanilla. This fixes the problem. I agree -- I don't use vanilla myself, but I know a lot of people do. As you suggest it's useful for testing the limits -- the sorting algorithms I implemented a year ago ([list-shellsort] in list-abs is one of them) are in this class of objects. I also think they're useful for teaching students who are intimidated by written code (almost all of my students are classically-trained composers) some things about algorithmic thinking. By underlining, I mean sometimes you don't know just how badly it's missing until you try to do it in Pd and check the results against the compiled libraries. [list-l2s] will never be as fast as [list2symbol] from zexy... etc. MB Games like you've done can be fun though. I've had fun with the [list-drip] speed hacks in february. But it was only a game. In real life I use [foreach], which is written in C++, and it works fine and faster than what's possible to do as a regular Pd patch. The game was only for testing limits and demonstrating unusual techniques (i mean techniques that are unusual in the context of pd; they may be commonplace in some other programming language). ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Vanilla [list-s2l] prototype
OK, here's a [list-s2l] with delimiting. This wasn't easy. =o) Included are all the abstractions needed -- [symbollength] calculates the length of a symbol. [list-l2f], as yet undocumented, attempts to build a float from an incoming stream of numbers and symbols -- works pretty well. I tried to get as close as possible to the behavior of zexy [s2l] and [list-l2s] ... It's probably not fast enough to use in practice, but it would be worth testing with small symbols to find out If you could test it, I could work out the bugs. I'd take suggestions, of course. Matt On Mon, Nov 16, 2009 at 6:22 PM, Matt Barber brbrof...@gmail.com wrote: Hello list, Attached is a prototype for a vanilla + list-abs [list-s2l]. I have leaned on the side of completeness and error reduction rather than efficiency -- there are many many ways to make this more efficient. Also, it doesn't handle delimiters yet (right now it breaks a symbol into its constituent characters, casting float symbols back to float), but I think I could figure out how to do it. Neither this nor [list-l2s] handles % appropriately... I'd appreciate any feedback. Matt #N canvas 281 56 684 695 10; #X obj 122 513 sel s; #X obj 143 361 makefilename %%.%ds; #X msg 143 388 set \$1; #X obj 48 212 until; #X obj 76 297 + 1; #X obj 33 623 f; #X obj 122 311 symbol; #X obj 48 238 t b b; #X obj 149 563 s \$0-stop; #X obj 122 539 t b b; #X obj 75 174 r \$0-stop; #X obj 192 468 print; #X obj 184 46 inlet; #X obj 184 174 t b b s; #X obj 184 73 route symbol; #X obj 33 644 outlet; #X obj 192 445 spigot 0; #X obj 237 423 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X obj 223 204 s \$0-sym; #X obj 122 280 r \$0-sym; #X obj 149 490 r \$0-sym; #X obj 122 422 makefilename; #X text 31 18 find length of symbol by iterating the first n characters ; #X text 276 362 - sprintf fun; #X text 266 423 - try this on; #X obj 48 297 f 1; #X msg 138 232 1; #X obj 157 145 sel s; #X obj 184 100 loadbang; #X msg 184 122 symbol; #X obj 208 262 s \$0-protect; #X obj 103 604 r \$0-protect; #X msg 103 627 0; #X connect 0 0 9 0; #X connect 1 0 2 0; #X connect 2 0 21 0; #X connect 3 0 7 0; #X connect 4 0 25 1; #X connect 5 0 15 0; #X connect 6 0 21 0; #X connect 7 0 6 0; #X connect 7 1 25 0; #X connect 9 0 5 0; #X connect 9 1 8 0; #X connect 10 0 3 1; #X connect 12 0 14 0; #X connect 13 0 3 0; #X connect 13 1 26 0; #X connect 13 2 18 0; #X connect 14 0 27 0; #X connect 16 0 11 0; #X connect 17 0 16 1; #X connect 19 0 6 1; #X connect 20 0 0 1; #X connect 21 0 0 0; #X connect 21 0 16 0; #X connect 25 0 4 0; #X connect 25 0 5 1; #X connect 25 0 1 0; #X connect 26 0 25 1; #X connect 27 0 30 0; #X connect 27 1 13 0; #X connect 28 0 29 0; #X connect 29 0 27 1; #X connect 31 0 32 0; #X connect 32 0 15 0; #N canvas 600 22 381 423 10; #N canvas 152 93 601 673 \$0-split-exp 0; #X obj 133 263 list-fifo-delim E; #X obj 133 174 until; #X obj 250 197 b; #X obj 250 263 b; #X obj 116 229 until; #X obj 133 197 list-fifo-delim e; #X obj 99 37 inlet; #X obj 231 357 f 1; #X msg 246 336 1; #X obj 246 315 r \$0-init; #X obj 267 357 + 1; #X obj 216 492 == 2; #X obj 216 517 sel 0; #X obj 216 470 f; #X obj 119 374 list prepend; #X obj 133 287 t a b; #X obj 119 401 route 1 2; #X obj 73 453 list; #X obj 123 453 list; #X obj 73 340 t b b b; #X obj 73 547 spigot; #X obj 123 547 spigot; #X obj 123 574 outlet; #X obj 73 574 outlet; #X obj 216 541 s \$0-not-float; #X obj 201 81 list-splat -1; #X obj 238 105 sel e E; #X obj 99 91 spigot; #X obj 99 118 t b b b a; #X obj 99 64 t a a; #X obj 151 37 r \$0-init; #X msg 151 59 1; #X msg 194 120 0; #X obj 238 152 s \$0-not-float; #X obj 238 128 t b b; #X connect 0 0 15 0; #X connect 0 1 3 0; #X connect 1 0 5 0; #X connect 2 0 1 1; #X connect 3 0 4 1; #X connect 4 0 0 0; #X connect 5 0 0 1; #X connect 5 1 2 0; #X connect 6 0 29 0; #X connect 7 0 10 0; #X connect 7 0 13 1; #X connect 7 0 14 1; #X connect 8 0 7 1; #X connect 9 0 8 0; #X connect 10 0 7 1; #X connect 11 0 12 0; #X connect 11 0 20 1; #X connect 11 0 21 1; #X connect 12 0 24 0; #X connect 13 0 11 0; #X connect 14 0 16 0; #X connect 15 0 14 0; #X connect 15 1 7 0; #X connect 16 0 17 1; #X connect 16 1 18 1; #X connect 17 0 20 0; #X connect 18 0 21 0; #X connect 19 0 17 0; #X connect 19 1 18 0; #X connect 19 2 13 0; #X connect 20 0 23 0; #X connect 21 0 22 0; #X connect 25 1 26 0; #X connect 26 0 34 0; #X connect 26 1 34 0; #X connect 27 0 28 0; #X connect 28 0 19 0; #X connect 28 1 4 0; #X connect 28 2 1 0; #X connect 28 3 5 1; #X connect 29 0 27 0; #X connect 29 1 25 0; #X connect 30 0 31 0; #X connect 31 0 27 1; #X connect 32 0 27 1; #X connect 34 0 33 0; #X connect 34 1 32 0; #X restore 69 167 pd \$0-split-exp; #X obj 71 109 s \$0-init; #N canvas 114 405 327 248 \$0-exp 0; #X obj 87 20 inlet; #N canvas 811 159 593 616 \$0-exp-filter 0; #X obj 157 54 list split 1; #X obj 292 147 list; #X obj 50 147 sel + -; #X obj 69 307 s \$0-neg-exp; #X msg 69 284 -1; #X obj 434 384 == 0; #X obj 454 340 int
Re: [PD] is there a way to get symbol length?
Here's a vanilla approach using the .n sprintf function of makefilename. Not completely tested... Matt Great! I tried to find a way of doing it in Vanilla but I couldn't!! I didn't think about this approach! Actually, after searching through the list archives, I believe you did think of it -- http://lists.puredata.info/pipermail/pd-list/2008-03/060393.html So, you know, kudos! MB ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Vanilla [list-s2l] prototype
Hello list, Attached is a prototype for a vanilla + list-abs [list-s2l]. I have leaned on the side of completeness and error reduction rather than efficiency -- there are many many ways to make this more efficient. Also, it doesn't handle delimiters yet (right now it breaks a symbol into its constituent characters, casting float symbols back to float), but I think I could figure out how to do it. Neither this nor [list-l2s] handles % appropriately... I'd appreciate any feedback. Matt #N canvas 443 63 631 589 10; #X obj 100 24 inlet; #X obj 161 534 outlet; #X obj 72 401 sel s; #X obj 155 209 makefilename %%.%ds; #X msg 155 232 set \$1; #X obj 159 95 s \$0-mainsym; #X obj 99 373 r \$0-mainsym; #X obj 182 440 list prepend; #X obj 161 506 list; #X obj 286 440 t a; #X obj 60 130 until; #X obj 147 181 + 1; #X obj 61 240 symbol; #X obj 119 181 f 1; #X obj 72 213 r \$0-mainsym; #X obj 100 78 t b b s; #X msg 134 158 1; #X obj 155 257 makefilename; #X obj 61 154 t b b; #X obj 182 334 list-lastx 2; #X msg 206 308 symbol; #X obj 155 300 t a a; #X obj 72 425 t b b; #X obj 99 450 s \$0-stop; #X obj 33 79 r \$0-stop; #X obj 251 411 r \$0-init; #X obj 206 284 r \$0-init; #X obj 146 129 s \$0-init; #X obj 100 47 route symbol; #X text 199 186 accumulate first n characters of symbol; #N canvas 580 22 514 754 \$0-find-next-char 0; #X obj 36 25 inlet; #X obj 109 716 outlet; #X obj 36 567 sel s; #X obj 36 189 until; #X obj 36 372 makefilename %c; #X msg 36 164 256; #X obj 36 220 f 0; #X obj 70 220 + 1; #X msg 88 189 0; #X obj 36 245 sel 123 125; #X obj 36 508 pack s s; #X obj 36 536 list-l2s; #X obj 36 460 symbol; #X obj 36 406 t b s; #X obj 109 675 symbol; #X obj 36 50 t b a b; #X obj 55 80 unpack s s; #X obj 55 132 s \$0-test; #X obj 112 106 s \$0-current; #X obj 96 550 r \$0-test; #X obj 107 443 r \$0-current; #N canvas 0 22 450 300 %0-float? 0; #X obj 133 91 inlet; #X obj 133 202 outlet; #X obj 222 201 outlet; #X obj 178 141 moses 58; #X obj 133 118 moses 48; #X connect 0 0 4 0; #X connect 3 0 2 0; #X connect 3 1 1 0; #X connect 4 0 1 0; #X connect 4 1 3 0; #X restore 99 267 pd %0-float?; #X obj 108 639 spigot; #X obj 168 641 spigot; #X obj 199 682 float; #X msg 227 342 1; #X obj 231 543 r \$0-spigot; #X obj 227 370 s \$0-spigot; #X obj 181 580 == 0; #X obj 36 284 t f b; #X msg 80 301 0; #X obj 168 325 t f f b; #X obj 227 658 - 48; #X obj 80 323 s \$0-spigot; #X text 99 525 test for match; #X text 274 658 - floats instead of symbols; #X text 81 417 previous match string plus test ascii value; #X text 132 178 -- iterate through all ascii values \, but don't make finding a match a condition for stopping the loop - we could make this more efficient by not testing all values \, and by making a match be a condition for stopping the loop.; #X connect 0 0 15 0; #X connect 2 0 22 0; #X connect 2 0 23 0; #X connect 3 0 6 0; #X connect 4 0 13 0; #X connect 5 0 3 0; #X connect 6 0 7 0; #X connect 6 0 9 0; #X connect 7 0 6 1; #X connect 8 0 6 1; #X connect 9 2 21 0; #X connect 10 0 11 0; #X connect 11 0 2 0; #X connect 12 0 10 0; #X connect 13 0 12 0; #X connect 13 1 10 1; #X connect 13 1 14 1; #X connect 14 0 1 0; #X connect 15 0 5 0; #X connect 15 1 16 0; #X connect 15 2 8 0; #X connect 16 0 17 0; #X connect 16 1 18 0; #X connect 19 0 2 1; #X connect 20 0 12 1; #X connect 21 0 29 0; #X connect 21 1 31 0; #X connect 22 0 14 0; #X connect 23 0 24 0; #X connect 24 0 1 0; #X connect 25 0 27 0; #X connect 26 0 23 1; #X connect 26 0 28 0; #X connect 28 0 22 1; #X connect 29 0 4 0; #X connect 29 1 30 0; #X connect 30 0 33 0; #X connect 31 0 4 0; #X connect 31 1 32 0; #X connect 31 2 25 0; #X connect 32 0 24 1; #X restore 182 374 pd \$0-find-next-char; #X text 313 377 find next character; #X text 267 331 compare last two chunks to look for the next character \; init with a blank symbol; #X text 33 468 stop when we've found all characters; #X connect 0 0 28 0; #X connect 2 0 22 0; #X connect 3 0 4 0; #X connect 4 0 17 0; #X connect 6 0 2 1; #X connect 7 0 8 1; #X connect 7 0 9 0; #X connect 8 0 1 0; #X connect 9 0 7 1; #X connect 10 0 18 0; #X connect 11 0 13 1; #X connect 12 0 17 0; #X connect 13 0 11 0; #X connect 13 0 3 0; #X connect 14 0 12 1; #X connect 15 0 10 0; #X connect 15 1 16 0; #X connect 15 1 27 0; #X connect 15 2 5 0; #X connect 16 0 13 1; #X connect 17 0 21 0; #X connect 18 0 12 0; #X connect 18 1 13 0; #X connect 19 0 30 0; #X connect 20 0 19 0; #X connect 21 0 2 0; #X connect 21 1 19 0; #X connect 22 0 8 0; #X connect 22 1 23 0; #X connect 24 0 10 1; #X connect 25 0 7 1; #X connect 26 0 20 0; #X connect 28 0 15 0; #X connect 30 0 7 0; #N canvas 22 119 674 278 10; #X obj 62 168 print; #X obj 259 125 list-s2l; #X obj 259 185 print; #X msg 259 71 symbol 1234567890abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwx...@#$*()_+~`./?[]| ; #X obj 332 142 unpack 0 0 0 0 0 0 0 0 0 0 s s; #X floatatom 332 204 5 0 0 0 - - -; #X floatatom 348 180 5 0 0 0 - - -; #X symbolatom 492 207 10 0 0 0 - - -; #X symbolatom 509 181 10 0 0 0 - -
[PD] Pd list down?
Hello, Was the Pd list down yesterday? It looks like the archive might be missing some conversations and posts. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] is there a way to get symbol length?
Here's a vanilla approach using the .n sprintf function of makefilename. Not completely tested... Matt On Nov 10, 2009, at 3:47 PM, Roman Haefeli wrote: On Tue, 2009-11-10 at 15:26 -0500, Ivica Ico Bukvic wrote: title says it all. Any external capable of doing this (other than resorting to something like a pyext)? Ico [symbol yoursymbol( | | [loadbang] | | | [symbol( - empty symbol | | [symbol2list] - from zexy | [list length] though, i haven't checked, if this approach still works, when the incoming symbol contains spaces (or other 'special' characters). roman That would make a nice object, like [symbollength]. .hc Making boring techno music is really easy with modern tools, he says, but with live coding, boring techno is much harder. - Chris McCormick -- ___ Pd-list mailing list Pd-list@iem.at to manage your subscription (including un-subscription) see http://lists.puredata.info/listinfo/pd-list End of Pd-list Digest, Vol 56, Issue 46 *** #N canvas 0 22 382 235 10; #X symbolatom 164 46 10 0 0 0 - - -; #X floatatom 164 182 5 0 0 0 - - -; #X msg 173 69 symbol dog; #X msg 181 94 symbol nugent; #X obj 45 89 makefilename %d; #X msg 45 63 6789; #X obj 164 153 symbollength; #X msg 193 122 symbol e; #X connect 0 0 6 0; #X connect 2 0 6 0; #X connect 3 0 6 0; #X connect 4 0 6 0; #X connect 5 0 4 0; #X connect 6 0 1 0; #X connect 7 0 6 0; #N canvas 297 111 465 610 10; #X obj 122 443 sel s; #X obj 143 291 makefilename %%.%ds; #X msg 143 318 set \$1; #X obj 48 142 until; #X obj 76 227 + 1; #X obj 33 553 f; #X obj 122 241 symbol; #X obj 48 168 t b b; #X obj 149 493 s \$0-stop; #X obj 122 469 t b b; #X obj 75 104 r \$0-stop; #X obj 192 398 print; #X obj 184 43 inlet; #X obj 184 104 t b b s; #X obj 184 77 route symbol; #X obj 33 574 outlet; #X obj 192 375 spigot 0; #X obj 237 353 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X obj 223 134 s \$0-sym; #X obj 122 210 r \$0-sym; #X obj 149 420 r \$0-sym; #X obj 122 352 makefilename; #X text 31 15 find length of symbol by iterating the first n characters ; #X text 276 292 - sprintf fun; #X text 266 353 - try this on; #X obj 48 227 f 1; #X msg 138 162 1; #X connect 0 0 9 0; #X connect 1 0 2 0; #X connect 2 0 21 0; #X connect 3 0 7 0; #X connect 4 0 25 1; #X connect 5 0 15 0; #X connect 6 0 21 0; #X connect 7 0 6 0; #X connect 7 1 25 0; #X connect 9 0 5 0; #X connect 9 1 8 0; #X connect 10 0 3 1; #X connect 12 0 14 0; #X connect 13 0 3 0; #X connect 13 1 26 0; #X connect 13 2 18 0; #X connect 14 0 13 0; #X connect 16 0 11 0; #X connect 17 0 16 1; #X connect 19 0 6 1; #X connect 20 0 0 1; #X connect 21 0 0 0; #X connect 21 0 16 0; #X connect 25 0 4 0; #X connect 25 0 5 1; #X connect 25 0 1 0; #X connect 26 0 25 1; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Thanks. I would like to work out the bugs if anyone could find this useful... I am too trusting with [print] so there were some things with floats that were actually phantom symbols (this kind of thing is really useful for learning lessons about the weird datatype pitfalls in Pd). Here's an update. I really wish there were some kind of [s2l] in vanilla. One COULD use something like # 2 instead of #2 and make it vanilla, but that seems kind of clunky. MB On Sat, Nov 14, 2009 at 6:18 PM, Hans-Christoph Steiner h...@at.or.at wrote: Yeah, its great that you made this. I think people are too used to thinking that some things are set in stone, like message boxes and arguments. But you really can make your own. And you did it in Pd event, bonus points there :-D .hc On Nov 14, 2009, at 5:45 PM, Matt Barber wrote: There are plenty of bugs still, but this might be the type of thing one could do without having to code a new object. On Sat, Nov 14, 2009 at 2:29 PM, Matt Barber brbrof...@gmail.com wrote: Here's a start -- it requires [s2l] and [l2s] from zexy, though (there may be a way to do it vanilla, but possibly not). Matt On Sat, Nov 14, 2009 at 11:35 AM, Mathieu Bouchard ma...@artengine.ca wrote: On Fri, 13 Nov 2009, Hans-Christoph Steiner wrote: Someone could write their own message box object and make it do whatever they want. Then you have both: a new interface and backwards compatibility. The message box could just be a GUI object like any other, there is nothing inherently unique about it. It wouldn't even need to be a GUI object. just make it an objectbox class named [m]. Then $1 (etc) becomes the same as in other objectboxes, and then another syntax can be used to mean message arguments. Except that if it's not a GUI object, then it's not clickable, and stuff. User-wise, there _is_ something inherently unique to the messagebox, but it happens to be exactly the difference that we'd like to eliminate. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 kill your television #N canvas 583 22 531 551 10; #N canvas 270 121 532 403 \$0-getargs 0; #X obj 37 40 inlet; #N canvas 31 427 359 254 \$0-construct_Iohannes_arg_test 0; #X obj 71 19 inlet; #X msg 218 155 vis 1; #X obj 71 172 outlet; #N canvas 497 46 421 150 \$0-connect 0; #X obj 25 25 inlet; #X obj 25 109 outlet; #X msg 25 47 connect 0 0 1 0 \, connect 1 0 8 0 \, connect 1 1 2 0 \, connect 2 0 3 0 \, connect 3 0 4 1 \, connect 8 0 4 0 \, connect 4 0 7 0 \, connect 4 1 5 0 \, connect 5 0 9 0 \, connect 9 0 6 0; #X connect 0 0 2 0; #X connect 2 0 1 0; #X restore 71 114 pd \$0-connect; #X obj 90 90 s \$0-construct_out; #X obj 89 139 r \$0-construct_out; #X obj 71 41 t b b f; #N canvas 557 172 523 728 \$0-step_1 0; #X obj 122 135 list trim; #X obj 79 380 list trim; #X obj 93 309 list trim; #X obj 108 206 f; #X obj 231 20 inlet; #X obj 205 405 outlet; #X msg 108 227 obj 10 40 t b b \, msg 200 57 \$1 \, obj 200 87 makefilename $%d- \, obj 10 104 select s \, obj 55 134 b; #X obj 50 20 inlet; #X obj 93 332 s \$0-step_1_out; #X obj 79 403 s \$0-step_1_out; #X obj 122 157 s \$0-step_1_out; #X obj 108 262 s \$0-step_1_out; #X obj 137 89 s \$0-step_1_out; #X obj 205 381 r \$0-step_1_out; #X obj 122 114 list append obj 10 10 r \$0-getcreationargs_in; #X obj 79 357 list append obj 10 224 s \$0-getcreationargs_noarg; #X obj 93 288 list append obj 55 194 s \$0-getcreationargs_thisarg ; #X obj 64 451 f; #X obj 64 473 makefilename $%d-; #X obj 64 515 list trim; #X obj 64 535 s \$0-step_1_out; #X obj 64 495 list prepend obj 10 70 symbol; #X obj 50 581 f; #X obj 50 606 makefilename $%d; #X obj 50 628 list prepend obj 55 164 list append; #X obj 51 648 list trim; #X obj 51 669 s \$0-step_1_out; #X obj 50 43 t b b b b b b b; #X msg 137 67 clear; #X obj 231 43 s \$0-arg-float; #X obj 65 560 r \$0-arg-float; #X obj 79 428 r \$0-arg-float; #X obj 123 183 r \$0-arg-float; #X connect 0 0 10 0; #X connect 1 0 9 0; #X connect 2 0 8 0; #X connect 3 0 6 0; #X connect 4 0 29 0; #X connect 6 0 11 0; #X connect 7 0 27 0; #X connect 13 0 5 0; #X connect 14 0 0 0; #X connect 15 0 1 0; #X connect 16 0 2 0; #X connect 17 0 18 0; #X connect 18 0 21 0; #X connect 19 0 20 0; #X connect 21 0 19 0; #X connect 22 0 23 0; #X connect 23 0 24 0; #X connect 24 0 25 0; #X connect 25 0 26 0; #X connect 27 0 22 0; #X connect 27 1 17 0; #X connect 27 2 15 0; #X connect 27 3 16 0; #X connect 27 4 3 0; #X connect 27 5 14 0; #X connect 27 6 28 0; #X connect 28 0 12 0; #X connect 30 0 22 1; #X connect 31 0 17 1; #X connect 32 0 3 1; #X restore 90 68 pd \$0-step_1; #X connect 0 0 6 0; #X connect 1 0 2 0; #X connect 3 0 2 0; #X connect 5 0 2 0; #X connect 6 0 3 0; #X connect 6 1 7 0; #X connect 6 2 7 1; #X connect 7 0 4 0; #X restore 76 164 pd \$0
Re: [PD] Finding $0 and dealing with it in messages
There are plenty of bugs still, but this might be the type of thing one could do without having to code a new object. On Sat, Nov 14, 2009 at 2:29 PM, Matt Barber brbrof...@gmail.com wrote: Here's a start -- it requires [s2l] and [l2s] from zexy, though (there may be a way to do it vanilla, but possibly not). Matt On Sat, Nov 14, 2009 at 11:35 AM, Mathieu Bouchard ma...@artengine.ca wrote: On Fri, 13 Nov 2009, Hans-Christoph Steiner wrote: Someone could write their own message box object and make it do whatever they want. Then you have both: a new interface and backwards compatibility. The message box could just be a GUI object like any other, there is nothing inherently unique about it. It wouldn't even need to be a GUI object. just make it an objectbox class named [m]. Then $1 (etc) becomes the same as in other objectboxes, and then another syntax can be used to mean message arguments. Except that if it's not a GUI object, then it's not clickable, and stuff. User-wise, there _is_ something inherently unique to the messagebox, but it happens to be exactly the difference that we'd like to eliminate. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finding $0 and dealing with it in messages
Here's a start -- it requires [s2l] and [l2s] from zexy, though (there may be a way to do it vanilla, but possibly not). Matt On Sat, Nov 14, 2009 at 11:35 AM, Mathieu Bouchard ma...@artengine.ca wrote: On Fri, 13 Nov 2009, Hans-Christoph Steiner wrote: Someone could write their own message box object and make it do whatever they want. Then you have both: a new interface and backwards compatibility. The message box could just be a GUI object like any other, there is nothing inherently unique about it. It wouldn't even need to be a GUI object. just make it an objectbox class named [m]. Then $1 (etc) becomes the same as in other objectboxes, and then another syntax can be used to mean message arguments. Except that if it's not a GUI object, then it's not clickable, and stuff. User-wise, there _is_ something inherently unique to the messagebox, but it happens to be exactly the difference that we'd like to eliminate. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 #N canvas 583 22 531 551 10; #N canvas 270 121 532 403 \$0-getargs 0; #X obj 37 40 inlet; #N canvas 31 427 359 254 \$0-construct_Iohannes_arg_test 0; #X obj 71 19 inlet; #X msg 218 155 vis 1; #X obj 71 172 outlet; #N canvas 497 46 421 150 \$0-connect 0; #X obj 25 25 inlet; #X obj 25 109 outlet; #X msg 25 47 connect 0 0 1 0 \, connect 1 0 8 0 \, connect 1 1 2 0 \, connect 2 0 3 0 \, connect 3 0 4 1 \, connect 8 0 4 0 \, connect 4 0 7 0 \, connect 4 1 5 0 \, connect 5 0 9 0 \, connect 9 0 6 0; #X connect 0 0 2 0; #X connect 2 0 1 0; #X restore 71 114 pd \$0-connect; #X obj 90 90 s \$0-construct_out; #X obj 89 139 r \$0-construct_out; #X obj 71 41 t b b f; #N canvas 557 172 523 728 \$0-step_1 0; #X obj 122 135 list trim; #X obj 79 380 list trim; #X obj 93 309 list trim; #X obj 108 206 f; #X obj 231 20 inlet; #X obj 205 405 outlet; #X msg 108 227 obj 10 40 t b b \, msg 200 57 \$1 \, obj 200 87 makefilename $%d- \, obj 10 104 select s \, obj 55 134 b; #X obj 50 20 inlet; #X obj 93 332 s \$0-step_1_out; #X obj 79 403 s \$0-step_1_out; #X obj 122 157 s \$0-step_1_out; #X obj 108 262 s \$0-step_1_out; #X obj 137 89 s \$0-step_1_out; #X obj 205 381 r \$0-step_1_out; #X obj 122 114 list append obj 10 10 r \$0-getcreationargs_in; #X obj 79 357 list append obj 10 224 s \$0-getcreationargs_noarg; #X obj 93 288 list append obj 55 194 s \$0-getcreationargs_thisarg ; #X obj 64 451 f; #X obj 64 473 makefilename $%d-; #X obj 64 515 list trim; #X obj 64 535 s \$0-step_1_out; #X obj 64 495 list prepend obj 10 70 symbol; #X obj 50 581 f; #X obj 50 606 makefilename $%d; #X obj 50 628 list prepend obj 55 164 list append; #X obj 51 648 list trim; #X obj 51 669 s \$0-step_1_out; #X obj 50 43 t b b b b b b b; #X msg 137 67 clear; #X obj 231 43 s \$0-arg-float; #X obj 65 560 r \$0-arg-float; #X obj 79 428 r \$0-arg-float; #X obj 123 183 r \$0-arg-float; #X connect 0 0 10 0; #X connect 1 0 9 0; #X connect 2 0 8 0; #X connect 3 0 6 0; #X connect 4 0 29 0; #X connect 6 0 11 0; #X connect 7 0 27 0; #X connect 13 0 5 0; #X connect 14 0 0 0; #X connect 15 0 1 0; #X connect 16 0 2 0; #X connect 17 0 18 0; #X connect 18 0 21 0; #X connect 19 0 20 0; #X connect 21 0 19 0; #X connect 22 0 23 0; #X connect 23 0 24 0; #X connect 24 0 25 0; #X connect 25 0 26 0; #X connect 27 0 22 0; #X connect 27 1 17 0; #X connect 27 2 15 0; #X connect 27 3 16 0; #X connect 27 4 3 0; #X connect 27 5 14 0; #X connect 27 6 28 0; #X connect 28 0 12 0; #X connect 30 0 22 1; #X connect 31 0 17 1; #X connect 32 0 3 1; #X restore 90 68 pd \$0-step_1; #X connect 0 0 6 0; #X connect 1 0 2 0; #X connect 3 0 2 0; #X connect 5 0 2 0; #X connect 6 0 3 0; #X connect 6 1 7 0; #X connect 6 2 7 1; #X connect 7 0 4 0; #X restore 76 164 pd \$0-construct_Iohannes_arg_test; #X obj 135 315 r \$0-getcreationargs_thisarg; #X obj 323 315 r \$0-getcreationargs_noarg; #X obj 56 211 s \$0-getcreationargs_in; #X obj 37 89 max 0; #X obj 37 64 route float; #X obj 37 110 int; #X obj 37 315 spigot 1; #X obj 82 262 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X obj 37 338 s pd-\$1; #X obj 135 338 outlet; #X obj 323 338 outlet; #X text 116 261 -- toggle on to see the result of the dynamic patching ; #X obj 82 290 == 0; #X text 147 55 Inlet: the argument number.; #X obj 37 134 t b b f; #X msg 37 237 clear \, editmode 0; #N canvas 0 22 450 300 \$0-helper 0; #X obj 10 10 r 1064-getcreationargs_in; #X obj 10 40 t b b; #X msg 200 57 17; #X obj 200 87 makefilename $%d-; #X obj 10 104 select s; #X obj 55 134 b; #X obj 55 194 s 1064-getcreationargs_thisarg; #X obj 10 224 s 1064-getcreationargs_noarg; #X obj 10 70 symbol \$17-; #X obj 55 164 list append \$17; #X connect 0 0 1 0; #X connect 1 0 8 0; #X connect 1 1 2 0; #X connect 2 0 3 0; #X connect 3 0 4 1; #X connect 4 0 7 0; #X connect 4 1 5 0; #X connect 5 0 9 0; #X connect 8 0 4 0; #X connect 9 0 6 0; #X restore 392 164 pd \$0-helper; #X obj 76 186 s pd-\$0-helper; #X text 147
Re: [PD] Finding $0 and dealing with it in messages
Without $0, one would have to use $1 ... $n for locality. $0 of a parent patch often needs to be passed as $1 to a child for proper locality, for instance, so I don't think they are necessarily THAT different conceptually. Matt On Fri, Nov 13, 2009 at 11:49 AM, Alexandre Porres por...@gmail.com wrote: Calling this an exception creates the impression, that $1 in a message is the same as in an object. Hmm, I see you have a point! But I am just used to consider $0 and $1, $2 ... $n different/separate things, being $0 solely a locality sintax. Putting them as separate concepts I see $1, $2 ... $n as two different things wether in messages or objects, and that $0 is just useless in messages. Anyway, I am cool with what needs to be done in order to put $0 in messages, I still think it's a bit of an unnecessary hassle, but it ain't that much of a big deal after all. The thing that had no other way around was using the Find feature to actually find them, so I thought about bringing this all up: the hassle and the problem. I now see that uncheking whole word in the new version is just another way around rather than actually getting the Find feature to look for $0, or even for the window number once we explicitly tell it which one it is. So, nerverminding about $0 in messages, I would still make a point here for the Find feature to be able to find $0, I hope it isn't much hassle getting it to do so. Thanks a bunch folks! Cheers alex On Fri, Nov 13, 2009 at 8:03 AM, Roman Haefeli reduzie...@yahoo.de wrote: Am 12.11.09 17:21 schrieb Alexandre Porres unter por...@gmail.com: But I totally disagree, I have been teaching a lot basic Pd around, and people always get confused and think they can just throw $0 in messages. So I have to state and reinforce that there is an exception that it doesn't work on messages. Calling this an exception creates the impression, that $1 in a message is the same as in an object. Without an exception at all, it should be easier to get it, as I understand. Agreed. But currently, the only thing that makes $0 in a message exceptional is the fact, that it has no meaning at all. Making it be replaced by the canvas identifier wouldn't make it less exceptional at all. 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] Finding $0 and dealing with it in messages
I am saying two things: 1) Without $0 or something similar, the only way to guarantee similar locality would be through use of $1 or $n -- you would have to manually give each instance an instance number. Sometimes you even want to be able to group instances in the way you suggested. I'm not sure of the history of Pd, but if $0 was implemented after abstractions with arguments, then manually assigning locality was probably necessary. 2) Sometimes $0 NEEDS to be inherited (probably as $1 or some such) by various helper abstractions within a larger, higher-functioning abstraction. This is especially the case with dynamic patching -- imagine, say, a bell synthesis patch using a dynamically created bank of enveloped oscillator abstractions. In that case, you'd want each oscillator abstraction to [throw~] to the same [catch~] within the parent instrument abstraction. To do this, you could have [catch~ $0-out] within the parent, and [throw $1-out] within each child, while passing the parent's $0 to the children. So all I'm saying is that $1-$n often plays a really important role in locality, in addition to a number of other things, and to me it seems almost natural to use $0 as an analogy for this role. I personally love the idea of using $0 as the selector of the abstraction -- its name or filename, and $$ as its ID, but too late for that now. Matt On Fri, Nov 13, 2009 at 3:01 PM, Alexandre Porres por...@gmail.com wrote: hmm, I am sorry, I don't think I got what you meant... could you give an example please? The way I see is that $1...$n are related to the inheritance concept. They could be used inside [send~] [receive~] objects to force some sort of locality, but you can't really guarantee locality by that, it is just some way around that is not 100% safe, cause if you have [s $1-gain] in an abstraction, and $1 inheriting A for instance, a [s A-gain] object in a parent patch (or even on another opened patch) would still get the value globally. cheers alex On Fri, Nov 13, 2009 at 5:28 PM, Matt Barber brbrof...@gmail.com wrote: Without $0, one would have to use $1 ... $n for locality. $0 of a parent patch often needs to be passed as $1 to a child for proper locality, for instance, so I don't think they are necessarily THAT different conceptually. Matt On Fri, Nov 13, 2009 at 11:49 AM, Alexandre Porres por...@gmail.com wrote: Calling this an exception creates the impression, that $1 in a message is the same as in an object. Hmm, I see you have a point! But I am just used to consider $0 and $1, $2 ... $n different/separate things, being $0 solely a locality sintax. Putting them as separate concepts I see $1, $2 ... $n as two different things wether in messages or objects, and that $0 is just useless in messages. Anyway, I am cool with what needs to be done in order to put $0 in messages, I still think it's a bit of an unnecessary hassle, but it ain't that much of a big deal after all. The thing that had no other way around was using the Find feature to actually find them, so I thought about bringing this all up: the hassle and the problem. I now see that uncheking whole word in the new version is just another way around rather than actually getting the Find feature to look for $0, or even for the window number once we explicitly tell it which one it is. So, nerverminding about $0 in messages, I would still make a point here for the Find feature to be able to find $0, I hope it isn't much hassle getting it to do so. Thanks a bunch folks! Cheers alex On Fri, Nov 13, 2009 at 8:03 AM, Roman Haefeli reduzie...@yahoo.de wrote: Am 12.11.09 17:21 schrieb Alexandre Porres unter por...@gmail.com: But I totally disagree, I have been teaching a lot basic Pd around, and people always get confused and think they can just throw $0 in messages. So I have to state and reinforce that there is an exception that it doesn't work on messages. Calling this an exception creates the impression, that $1 in a message is the same as in an object. Without an exception at all, it should be easier to get it, as I understand. Agreed. But currently, the only thing that makes $0 in a message exceptional is the fact, that it has no meaning at all. Making it be replaced by the canvas identifier wouldn't make it less exceptional at all. 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] Finding $0 and dealing with it in messages
If you're interested, there was a huge thread about this in February, starting about here: http://lists.puredata.info/pipermail/pd-list/2009-02/067889.html It continues, too -- it will look like the thread dies out, but if you look later in that month there will be many more posts with the same subject. Matt yep, sure, it works, but, anyway, I just think it would be easier for some operations if we could use $0 in messages, that's all... Thanks Cheers Alex ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] tab-abs
Ah, yes, thanks! I've said it before -- one of my favorite things about list-abs is their use in pedagogy -- you can get under the hood in them with music students and they don't have to learn C to do it (each of the list-abs objects could be written much more efficiently in C but it's nice to have them as abstractions, and vanilla abstractions at that). These iem_tab objects are great as far as use-within-a-patch is concerned, though, so again thanks. Maybe I'll make my own abstractions for pedagogy. Matt 2009/11/8 Raphaël Isdant raphael.isd...@free.fr: Hi, you should check into /pd/extra/iem_tab Raf - Original Message - From: Matt Barber brbrof...@gmail.com To: PD-List pd-list@iem.at Sent: Saturday, November 07, 2009 4:04 AM Subject: [PD] tab-abs Hello, I think this has been proposed before, so maybe I've missed it. Is there a library of abstractions for operations on tables akin to list-abs? If not, I'd like to consider how such a library might be organized A lot of the list-abs abstractions could be translated and used for tables. I could imagine for instance abstractions that would fill tables with various kinds of windows, and some that would implement such windows in a named table within the abstraction itself. Also, there might be abstractions that would perform the operations in-place, and some that would leave the source table intact and copy the results into another table. Etc. Has this been developed and/or discussed already? I would have a few to contribute. Matt ___ 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] Hot inlet position
And if ideally Pd should be just a musical instrument that you only have to tune and play, it's only to go with those musicians who ideally should understand the breadth and depth of Pd's potential, but in practice don't. Thanks so much for saying this. Think of the kind of acquired skill one needs to expertly tune and play, say, a violin, with mastery. The problem is how the phrase just a musical instrument is used -- if you can justify spending years learning scales so that you can play in tune and develop technical facility, learning how sound works so you can adjust the instrument, learning how music works so you can play it intelligently, learning how others before you came to master their instrument and how to develop critical opinions about their playing, etc., certainly you can justify the same kind of intense work for any instrument (electronic/acoustic/programmed/otherwise) if you care to become competent. Matt PS -- I expect my wife to wonder just what tons of emails about hot inlet position are doing in my inbox... =o) ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
