Pd-list December 2015

pd-list@lists.iem.at

56 participants
94 discussions

Re: [PD] standalone
by Dan Wilcox 14 Dec '15

14 Dec '15

PD uses 8.3 on OSX since, currently, it’s using a version of Wish Shell that came with 8.3. -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> > On Dec 14, 2015, at 11:44 AM, pd-list-request(a)lists.iem.at wrote: > > From: Simon Iten <itensimon(a)gmail.com <mailto:itensimon@gmail.com>> > Subject: Re: [PD] standalone > Date: December 14, 2015 at 11:44:00 AM MST > To: IOhannes m zmölnig <zmoelnig(a)iem.at <mailto:zmoelnig@iem.at>> > Cc: pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at> > > > kiosk plugin looks great! > > osx pd says this, arrgh i hate it…(linux is so much easier in this regard) > > > UNHANDLED ERROR: version conflict for package "Tcl": have 8.4, need 8.5 > while executing > "package require Tcl 8.5" > ("uplevel" body line 9) > invoked from within > "uplevel #0 $tclcode" > FAILED TO LOAD /Users/lokki/Library/Pd/kiosk-plugin/kiosk-plugin.tcl > ----------- > ----------- > UNHANDLED ERROR: version conflict for package "Tcl": have 8.4, need 8.5 > while executing > "package require Tcl 8.5" > ("uplevel" body line 9) > invoked from within > "uplevel #0 $tclcode" > FAILED TO LOAD /Users/lokki/Library/Pd/kiosk-plugin.tcl > > does this mean the version of tcl used in the pd package app is outdated? (since i compiled 8.6 from source, but i am pretty sure pd just uses the internal one)

2 2

Pd network sniffer
by Olivier Baudu 14 Dec '15

14 Dec '15

Hi list, I'm searching a pd network sniffer... I knew PDPCAP : http://musa.poperbu.net/index.php/tecnologia-seccions-30/-puredata-seccions… But there is no archive anymore (well, I can't find it, to be honest). Does anyone have a version of the project somewhere ? Or, an other "pd native" way to sniff network ? Thanks... °1 -- "On ne peut pas vivre dans un monde où l'on croit que l'élégance exquise du plumage de la pintade est inutile. Ceci est tout à fait à part. J'ai eu envie de le dire, je l'ai dit." Jean Giono, Un roi sans divertissement.

4 12

Re: [PD] standalone
by Samuel Burt 14 Dec '15

14 Dec '15

Couldn't you use GUI objects for your interface sending them all into a [pd~] object to run a copy of Pd with no gui in the background? The only thing they could break then would be connections between the GUI and [pd~] which could be nested away in a subpatch covered by a canvas. Unfortunately, I don't think there is a way to prevent unlocking of the patcher window, although perhaps you could look for the control/cmd-E press and then automatically send a command to Pd to lock the patcher again. (This could get really annoying if you need to edit it.) Sam > >> 2015-12-14 17:15 GMT+01:00 Py Fave <pyfave(a)gmail.com>: > >> > >>> you can make an interface using gem so it appears on top > >>> > >>> but it can lead to sound glitches > >>> > >>> 2015-12-14 17:09 GMT+01:00 Alexandre Torres Porres <porres(a)gmail.com>: > >>> > >>>> > an interface that just works and where nothing can go “wrong” > >>>> > >>>> I've made installations for not very computer savy people to run them. > >>>> > >>>> All they had to do was click on a pd file to open, adjust one or two > >>>> interface GUI > >>>> > >>>> nothing went wrong. > >>>> > >>>> I guess it's a matter of how and what you do > >>>> > >>>> 2015-12-14 13:29 GMT-02:00 Simon Iten <itensimon(a)gmail.com>: > >>>> > >>>>> > >>>>> > On 14 Dec 2015, at 16:20, IOhannes m zmölnig <zmoelnig(a)iem.at> > >>>>> wrote: > >>>>> > > >>>>> > On 12/14/2015 03:56 PM, Simon Iten wrote: > >>>>> >> hi list, > >>>>> >> > >>>>> >> are there any efforts to make “standalone” pd vanilla apps > possible? > >>>>> >> > >>>>> >> what i mean is a clickable program, that runs a pd patch without > >>>>> the options to enter edit mode. (or even better a pd-light for > pd-patches > >>>>> that just shows the patch wihtout any other menus except for audio > and midi > >>>>> device setup) > >>>>> >> > >>>>> >> i guess it should not be too hard to do a version of pd vanilla > >>>>> that disables all those menu entries. > >>>>> >> > >>>>> > > >>>>> > there's the kiosk-plugin, that allows you to disable most > >>>>> interaction. > >>>>> > >>>>> i’ll check it out, thanks > >>>>> > > >>>>> > apart from that, i don't think there is much effort going into > >>>>> something > >>>>> > "standalone" (with the argument being, that a reduced standalone > app > >>>>> is > >>>>> > needed only if you have to pay for the full app - which does not > >>>>> apply > >>>>> > with Pd). > >>>>> > >>>>> i think this is not true at all. the point of the standalone app in > >>>>> the case of pd would be to present to a not very computer savy > person an > >>>>> interface that just works and where nothing can go “wrong” by > clicking in > >>>>> the wrong places or by hitting some keycombinations. but maybe that > is what > >>>>> kiosk is doing already. > >>>>> > > >>>>> > famsrd > >>>>> > IOhannes > >>>>> > >

1 0

[sharing] Controlling Audio Settings with a Message
by Peter Nyboer 14 Dec '15

14 Dec '15

Hi all, new here. I recently was trying to figure out a way to disable audio input from a message, and I couldn’t find it. Fortunately, I had some help from Tom Erbe, who wised me to this nugget: ; pd audio-dialog 3 0 0 0 0 0 0 0 3 0 0 0 1 0 0 0 41000 25 0 64 This follows the same pattern as the variables declared in dialog_audio.tcl: audio_indev1 audio_indev2 audio_indev3 audio_indev4 audio_inchan1 audio_inchan2 audio_inchan3 audio_inchan4 audio_outdev1 audio_outdev2 audio_outdev3 audio_outdev4 audio_outchan1 audio_outchan2 audio_outchan3 audio_outchan4 audio_sr audio_advance audio_callback audio_blocksize Use integers to select the items in the input and output menus, and use 0 and 1 to enable/disable the input devices and output devices. In hopes that a present or future Puredata user finds this useful!!! Peter

2 1

PureData MIDI Device Problem
by Aiichiro HAYASHI 14 Dec '15

14 Dec '15

Hi, I found a MIDI device problem on PureData. I found PureData recognizes only up to 20 MIDI Devices. I use PureData 0.46.7 on my Mac mini, PureData recognizes only first 20 MIDI Devices while I have over 50 or more (and more) MIDI devices on line and I cannot select the device I want to use. Does anyone meet same situation like me??? -- Aiichiro HAYASHI (i16) -- http://i16.jp

1 0

control objects and dsp
by Jonathan Wilkes 13 Dec '15

13 Dec '15

Hi list,Would it be worth it to refrain from restarting dsp when a control object is deleted? -Jonathan

1 0

no "clear" message option in [cyclone/delay~], [delwrite~] and [z~]
by Alexandre Torres Porres 13 Dec '15

13 Dec '15

As discussed in the previous thread, we can't clear delay buffers in Pd (you can do it with tapin~ in max, for instance), at least not with [delwrite~], [delay~] and [z~]. So we're pretty much tied up and needed it for an "moving sum" object or a "moving average" filter. It doesn't seem hard to allow a "clear" message into delwrite~ for the next update. [delay~] in Max actually can also clear, so we could add this feature in [cyclone/delay~]! and [z~] could also be cleared, maybe, why not? cheers

6 16

0 length delay in delwrite~
by Alexandre Torres Porres 13 Dec '15

13 Dec '15

hi, I'm checking that if you put a 0 length delay in delwrite~ you still have some buffer what's up with that? and how does it work? how big is it when you don't define it? I always get a minimum dealy even with order forcing (and different values depending on extended orvanilla), it seems the delay needs to be at least the block size to work properly moreover, I can't have an order forcing thanks

5 24

setting previous samples in [z~] (was cyclone features)
by Alexandre Torres Porres 13 Dec '15

13 Dec '15

Hi Fred, I'll answer you here > What do you mean by setting samples in the delay line? > I tried understanding what fexpr~ does with [set ...( but failed miserable :-( first, I mean that regarding [z~], [delay~] in max doesn't have this. What it does is you can set the values of the previous samples, in fexpr you can set values for any delay line in it, both inputs ($x1[-1], $x3[-4]) and outputs ($y2[-2] etc). You can also clear it (0 everywhere). I think it's another cool feature to add to [z~] besides clearing it. say you have a constant signal = 1 into your delay line and it is 5 samples long (1 1 1 1 1) - the leftmost being the first samples of the delay line you can go and set different values for them like this, lets set $x1[-1] and $x1[-2] to 0 and 0.5 now it's 0 0.5 1 1 1 and the samples we've set will quickly be overwritten by the constant signal of "1" hope this does it. cheers 2015-12-13 8:06 GMT-02:00 Fred Jan Kraan <fjkraan(a)xs4all.nl>: > Hi Alexandre, > > Cool, works, and if your planing on doing something, besides a clear >> message you could also think of a "set" message where it receives a list >> of numbers setting the samples in the delay line (max list size = delay >> size). >> > > The [clear( message is as simple as DSP can get; just zero the entire > buffer. Most other operations are more complex. What do you mean by setting > samples in the delay line? Trying to set more than a few will get very > inefficient, and from the message domain it will be hard to control where > they be placed in the signal stream. > >> >> The "set" message would really make it much more powerful ;) - reminding >> that delay~ and delwrite~ don't have this, only fexpr~ >> > > I tried understanding what fexpr~ does with [set ...( but failed miserable > :-(. > >> >> Let me know how you feel about the suggestion, and when you could do >> that if you're considering adding such features. >> > > About the feature requests, maybe you could try to make a persistent > overview (web page or in the http://puredata.info wiki)? Trying to find > them in this list later is no fun, and it will be useful when I or some > future cyclone maintainer might find the time to implement them. It allows > for some extra explanation and maybe an abstraction to demonstrate the > feature. > > I just managed to install the Max/MSP 4.6 help patches and counted 470 > objects there. Count 100 for vanilla Pd and 150 for cyclone, there are 220 > to go... > >> >> cheers >> > > Greetings, > > Fred Jan > >> >> 2015-12-11 20:08 GMT-02:00 IOhannes m zmölnig <zmoelnig(a)iem.at >> <mailto:zmoelnig@iem.at>>: >> >> On 12/11/2015 11:01 PM, Alexandre Torres Porres wrote: >> > 2015-12-08 17:16 GMT-02:00 Christof Ressi <christof.ressi(a)gmx.at >> <mailto:christof.ressi@gmx.at>>: >> > >> >> Actually, [z~] is cleared everytime you change the right inlet >> > >> > >> > Although it serves well for the mean filter, I just came across the >> need to >> > clear the buffer for the same delay size, so I can't use [z~] or >> [delay~] >> > or [delwrite~]/[delread~]... >> > >> > so only option is [fexpr~] - which has a block limit but suits me >> > >> > anyway, not a bad idea to add a clear method to [z~] anyway >> >> how about giving [z~] a dummy delay (e.g. 'required+1') to trigger the >> clearing, and then set it back to the original value ('required')? >> not very elegant, but works *now*. >> >> fmadsr >> IOhannes >> >> >> _______________________________________________ >> Pd-list(a)lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >> >> >> >> _______________________________________________ >> Pd-list(a)lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >>

1 0

Help
by corentin THIERCELIN 13 Dec '15

13 Dec '15

Help Le 13 déc. 2015 16:25, pd-list-request(a)lists.iem.at a écrit : Send Pd-list mailing list submissions to pd-list(a)lists.iem.at To subscribe or unsubscribe via the World Wide Web, visit http://lists.puredata.info/listinfo/pd-list or, via email, send a message with subject or body 'help' to pd-list-request(a)lists.iem.at You can reach the person managing the list at pd-list-owner(a)lists.iem.at When replying, please edit your Subject line so it is more specific than "Re: Contents of Pd-list digest..." Today's Topics: 1. Re: 0 length delay in delwrite~ (Christof Ressi) 2. Re: 0 length delay in delwrite~ (Matt Barber) ---------------------------------------------------------------------- Message: 1 Date: Sun, 13 Dec 2015 14:01:02 +0100 From: "Christof Ressi" <christof.ressi(a)gmx.at> To: "Alexandre Torres Porres" <porres(a)gmail.com> Cc: i go bananas <hard.off(a)gmail.com>, "pd-list(a)lists.iem.at" <pd-list(a)lists.iem.at> Subject: Re: [PD] 0 length delay in delwrite~ Message-ID: <trinity-26517955-f91f-441d-bebb-4d64585c8fec-1450011662710@3capp-gmx-bs10> Content-Type: text/plain; charset=UTF-8 > don't work for block size < 64 true! mea culpa. just write [delwrite~ 1.5] + [delread~ 0] and everything's fine :-). > Those two things means the same to me, where maximum delay time = buffer size. I don't get this. The are *not* the same. I'll try to explain it: If you just want to send a signal (without delaying it), you still need a buffer for writing a signal block, which all the receive objects can then read from. Let's say the buffer size is 64 samples. If you, however, want to have a delay, you have to add a certain amount of samples according to the desired maximum delay time. If you want a max. delay of 1 second, you have to add 44100 samples. So the actual buffer size is 44164 samples. The delay time is really just a offset to your index in a ring buffer. Let's suppose one of the [delread~] objects is operating on a block size of 1024: the necessary size for reading without any delay is now 960 samples larger (1024-64), so in the buffer there are less samples left for actually delaying the signal: the maximum delay time for this particular [delread~] object is only 43410 samples. Of course Miller could add some complicated mechanism for [delwrite~] to keep track of all the block sizes of its [delread~] objects, but to me the simplest solution is updating the docs and stating: "max. delay time = buffer size - block size of [delread~]" > I might see an issue if delread~ is in a subpatch that has a longer block size, but I don't wee why anyone would need that, and perhaps just say you shouldn't do it. I *have* to do it when I read a delay line from inside a fft subpatch where the blocksize is of course larger than the one from the parent patch (didn't you have to do that as well? We talked about that in the thread concerning your phase vocoder issues a couple of months ago). BTW: having a [delread~] at a smaller block size than the [delwrite~] will create junk output because [delread~] will read at a faster rate than [delwrite~] can actually update the buffer, leading to weird looking repetitions in the waveform. Gesendet: Samstag, 12. Dezember 2015 um 18:00 Uhr Von: "Alexandre Torres Porres" <porres(a)gmail.com> An: "Roman Haefeli" <reduzent(a)gmail.com>, "i go bananas" <hard.off(a)gmail.com>, "Christof Ressi" <christof.ressi(a)gmx.at>, "Miller Puckette" <mpuckett(a)imusic1.ucsd.edu> Cc: "pd-list(a)lists.iem.at" <pd-list(a)lists.iem.at> Betreff: Re: [PD] 0 length delay in delwrite~ > Order forcing works well for me. Just set the [delwrite~] to 10 ( but weirdness arises from 0 length delay. > If a delay of zero WAS actually permitted, these would form infinite loops. Don't think so, depends on what a 0 delay is. If it is "no delay", and by that I mean "No Buffer", then it only outputs 0 values, right?. In other words, nothing happens, no infinite loop, nothing, just zeros... but if instead of zeros it does have some buffer length in it, then a feedback delay will always de delayed at least one block size, so no worries about feedback loop. Actually, you need to set delread to "0" for a minimum block size delay. Perhaps you meant you couldn't or shouldn't put a "0" delay time in the delread~ object for feedback, but actually you NEED to do that. Thing is that I just use delwrite~ and delread~ with 0 length arguments for both and a block size of 1 to allow single sample feedback. I do it cause I wanted the minimum delay buffer size as possible and I didn't want to write in tiny and long and boring numbers according to one sample size depending on sample rate. Since it was working, I had just always assumed it would create a buffer of one block. This is not what's really happening as I see it. I don't really care that much on what happens, doesn't seem like a big deal, but it was nice to understand this behaviour. It doesn't seem very consistent, that's all I can say... Now, what it actually does is really just a matter of design choices. It could very much just create no delay buffer at all, where you'd get 0 values perhaps, like I imagined. That's silly anyway... Or... it could be only one sample... or one block... I had assumed out of nowhere that it could be a block size, but it could much be just a single sample, which seems to make sense and it'd be cool I guess. What's really bad is that you need to always put a value that is at least one block size. It's a bug considering the documentation clearly stated that the design was really supposed to be a delay between 0 and max delay size, but one way or another, it's really annoying doing all this math as a workaround, when it's just a matter of coding it properly to allow any size greater than 0 and smaller than a block size (in orther words, to fix it). > If you, however, want a simple block delay in a feedback loop, > just use a pair of [send~] and [receive~]. don't work for block size < 64 > specifying the buffer size makes much more > sense then giving a maximum delay time Those two things means the same to me, where maximum delay time = buffer size. I don't get this. > [delwrite~] object would need to keep track of this sure, whatever, why not? by the way, that's the one that defines the max delay length (or buffer size), (and there can be only one, by the way) - so it only needs to keep track of its block size to work out the proper buffer size. I might see an issue if delread~ is in a subpatch that has a longer block size, but I don't wee why anyone would need that, and perhaps just say you shouldn't do it. I think we've discussed this before, perhaps just make sure both are in the same block size. I for one, never needed them to be in different block sizes, makes no useful sense. But anyway, I guess Miller is the one that should hop in and share his thoughts. and lets not forget the "clear" method, also important :) cheers 2015-12-12 12:33 GMT-02:00 Roman Haefeli <reduzent(a)gmail.com>: On Fri, 2015-12-11 at 14:26 -0200, Alexandre Torres Porres wrote: > hi, I'm checking that if you put a 0 length delay in delwrite~ you > still have some buffer > > > what's up with that? and how does it work? how big is it when you > don't define it? Don't know. I confirm that weirdness happens when setting [delwrite~] to 0. In other words: The only value that does not justify using a delay at all shows unexpected behavior. I can live with that. > I always get a minimum dealy even with order forcing (and different > values depending on extended orvanilla), it seems the delay needs to > be at least the block size to work properly > > > moreover, I can't have an order forcing Order forcing works well for me. Just set the [delwrite~] to 10 (and [delread~] to 0) in your patch and the number box shows 0 (this means zero delay, right?). Roman _______________________________________________ Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/list… ------------------------------ Message: 2 Date: Sun, 13 Dec 2015 10:23:31 -0500 From: Matt Barber <brbrofsvl(a)gmail.com> To: Christof Ressi <christof.ressi(a)gmx.at> Cc: "pd-list(a)lists.iem.at" <pd-list(a)lists.iem.at>, i go bananas <hard.off(a)gmail.com> Subject: Re: [PD] 0 length delay in delwrite~ Message-ID: <CAOrke7H68ea46v_TiHPxBxzg8oduApvRqPjLCR5Kqcw2MP3N6w(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" > > BTW: having a [delread~] at a smaller block size than the [delwrite~] will > create junk output because [delread~] will read at a faster rate than > [delwrite~] can actually update the buffer, leading to weird looking > repetitions in the waveform. I think this is more a function of the way [delread~] is written: it doesn't maintain its own phase in the buffer but rather indexes from the current [delwrite~] phase. If the latter has a larger blocksize,, then [delread~] will repeat some blocks and then jump once the [delwrite~] is updated. Getting [delread~] to maintain its own phase is very tricky (after all the nature of delay means indexing from the writehead); it's not impossible, but far from trivial. On Sun, Dec 13, 2015 at 8:01 AM, Christof Ressi <christof.ressi(a)gmx.at> wrote: > > don't work for block size < 64 > > true! mea culpa. just write [delwrite~ 1.5] + [delread~ 0] and > everything's fine :-). > > > > Those two things means the same to me, where maximum delay time = buffer > size. I don't get this. > > The are *not* the same. I'll try to explain it: > If you just want to send a signal (without delaying it), you still need a > buffer for writing a signal block, which all the receive objects can then > read from. Let's say the buffer size is 64 samples. If you, however, want > to have a delay, you have to add a certain amount of samples according to > the desired maximum delay time. If you want a max. delay of 1 second, you > have to add 44100 samples. So the actual buffer size is 44164 samples. The > delay time is really just a offset to your index in a ring buffer. Let's > suppose one of the [delread~] objects is operating on a block size of 1024: > the necessary size for reading without any delay is now 960 samples larger > (1024-64), so in the buffer there are less samples left for actually > delaying the signal: the maximum delay time for this particular [delread~] > object is only 43410 samples. > > Of course Miller could add some complicated mechanism for [delwrite~] to > keep track of all the block sizes of its [delread~] objects, but to me the > simplest solution is updating the docs and stating: "max. delay time = > buffer size - block size of [delread~]" > > > > I might see an issue if delread~ is in a subpatch that has a longer > block size, but I don't wee why anyone would need that, and perhaps just > say you shouldn't do it. > > I *have* to do it when I read a delay line from inside a fft subpatch > where the blocksize is of course larger than the one from the parent patch > (didn't you have to do that as well? We talked about that in the thread > concerning your phase vocoder issues a couple of months ago). > > BTW: having a [delread~] at a smaller block size than the [delwrite~] will > create junk output because [delread~] will read at a faster rate than > [delwrite~] can actually update the buffer, leading to weird looking > repetitions in the waveform. > > > > Gesendet: Samstag, 12. Dezember 2015 um 18:00 Uhr > Von: "Alexandre Torres Porres" <porres(a)gmail.com> > An: "Roman Haefeli" <reduzent(a)gmail.com>, "i go bananas" < > hard.off(a)gmail.com>, "Christof Ressi" <christof.ressi(a)gmx.at>, "Miller > Puckette" <mpuckett(a)imusic1.ucsd.edu> > Cc: "pd-list(a)lists.iem.at" <pd-list(a)lists.iem.at> > Betreff: Re: [PD] 0 length delay in delwrite~ > > > Order forcing works well for me. Just set the [delwrite~] to 10 ( > > but weirdness arises from 0 length delay. > > > If a delay of zero WAS actually permitted, these would form infinite > loops. > > Don't think so, depends on what a 0 delay is. If it is "no delay", and by > that I mean "No Buffer", then it only outputs 0 values, right?. In other > words, nothing happens, no infinite loop, nothing, just zeros... > > but if instead of zeros it does have some buffer length in it, then a > feedback delay will always de delayed at least one block size, so no > worries about feedback loop. > > Actually, you need to set delread to "0" for a minimum block size delay. > Perhaps you meant you couldn't or shouldn't put a "0" delay time in the > delread~ object for feedback, but actually you NEED to do that. > > Thing is that I just use delwrite~ and delread~ with 0 length arguments > for both and a block size of 1 to allow single sample feedback. I do it > cause I wanted the minimum delay buffer size as possible and I didn't want > to write in tiny and long and boring numbers according to one sample size > depending on sample rate. > > Since it was working, I had just always assumed it would create a buffer > of one block. > > This is not what's really happening as I see it. > > I don't really care that much on what happens, doesn't seem like a big > deal, but it was nice to understand this behaviour. It doesn't seem very > consistent, that's all I can say... > > Now, what it actually does is really just a matter of design choices. It > could very much just create no delay buffer at all, where you'd get 0 > values perhaps, like I imagined. That's silly anyway... > > Or... it could be only one sample... or one block... I had assumed out of > nowhere that it could be a block size, but it could much be just a single > sample, which seems to make sense and it'd be cool I guess. > > What's really bad is that you need to always put a value that is at least > one block size. It's a bug considering the documentation clearly stated > that the design was really supposed to be a delay between 0 and max delay > size, but one way or another, it's really annoying doing all this math as a > workaround, when it's just a matter of coding it properly to allow any size > greater than 0 and smaller than a block size (in orther words, to fix it). > > > If you, however, want a simple block delay in a feedback loop, > > just use a pair of [send~] and [receive~]. > > don't work for block size < 64 > > > specifying the buffer size makes much more > > sense then giving a maximum delay time > > Those two things means the same to me, where maximum delay time = buffer > size. I don't get this. > > > [delwrite~] object would need to keep track of this > > sure, whatever, why not? > > by the way, that's the one that defines the max delay length (or buffer > size), (and there can be only one, by the way) - so it only needs to keep > track of its block size to work out the proper buffer size. > > I might see an issue if delread~ is in a subpatch that has a longer block > size, but I don't wee why anyone would need that, and perhaps just say you > shouldn't do it. > > I think we've discussed this before, perhaps just make sure both are in > the same block size. I for one, never needed them to be in different block > sizes, makes no useful sense. > > But anyway, I guess Miller is the one that should hop in and share his > thoughts. > > and lets not forget the "clear" method, also important :) > > cheers > > > 2015-12-12 12:33 GMT-02:00 Roman Haefeli <reduzent(a)gmail.com>: > On Fri, 2015-12-11 at 14:26 -0200, Alexandre Torres Porres wrote: > > hi, I'm checking that if you put a 0 length delay in delwrite~ you > > still have some buffer > > > > > > what's up with that? and how does it work? how big is it when you > > don't define it? > > Don't know. I confirm that weirdness happens when setting [delwrite~] to > 0. In other words: The only value that does not justify using a delay at > all shows unexpected behavior. I can live with that. > > > I always get a minimum dealy even with order forcing (and different > > values depending on extended orvanilla), it seems the delay needs to > > be at least the block size to work properly > > > > > > moreover, I can't have an order forcing > > Order forcing works well for me. Just set the [delwrite~] to 10 (and > [delread~] to 0) in your patch and the number box shows 0 (this means > zero delay, right?). > > Roman > > > _______________________________________________ > Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/list… > > > _______________________________________________ > Pd-list(a)lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >

2 1

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Pd-list December 2015