Re: [PD] pasted objects now end up under the original object
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: Yeah, Copy-Paste needs work. It should probably paste based on mouse cursor location. If I paste I usually don't care where the mouse cursor is, and quite often it's not even over the window I'm pasting into - for example when I copy stuff from one patch window into another, I select stuff with the mouse in window 1, copy it with Ctl-V, then Alt-TAB over to window 2 and paste. There is no mouse over window 2 then, and if there would be, it would be in a random position. Pasting where the objects where before makes more sense. Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] recirculating delay line reverberation time calculation
hi all, I don't think anyone knows the answer to this. Traditionally, ever since Schroeder's reverberator, I think people have used delay times within a ratio of 1.5:1 of each other so that any old mean works OK. cheers Miller On Fri, Aug 29, 2008 at 10:07:30PM +0100, Claude Heiland-Allen wrote: Hi all, Referring to Miller's book [1], and having experimented with various delay times, I'm wondering what the average delay time used in the text is. If all the delay times are close to equal, then using the arithmetic mean as average gives me a reasonably accurate reverberation time calculation. But the more they differ the worse the result is (comparing with measurement against my implementation). [1] http://crca.ucsd.edu/~msp/techniques/latest/book-html/node111.html Intuitively it seems that the sound recirculates more often (and is thus attenuated more) through the shorter delay lines, but this is obviously not taken into account with arithmetic mean. I'm thinking something like harmonic mean might be better (but I tried it and it wasn't a huge improvement, nor was geometric mean). Any clarification would be enlightening, thanks, Claude -- http://claudiusmaximus.goto10.org ___ 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] pasted objects now end up under the original object
So, maybe, one should only paste to where the cursor is when the copy and paste are in the same window? hmm... M On Mon, Sep 01, 2008 at 10:50:28AM +0200, Frank Barknecht wrote: Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: Yeah, Copy-Paste needs work. It should probably paste based on mouse cursor location. If I paste I usually don't care where the mouse cursor is, and quite often it's not even over the window I'm pasting into - for example when I copy stuff from one patch window into another, I select stuff with the mouse in window 1, copy it with Ctl-V, then Alt-TAB over to window 2 and paste. There is no mouse over window 2 then, and if there would be, it would be in a random position. Pasting where the objects where before makes more sense. Ciao -- Frank Barknecht _ __footils.org__ ___ 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] Fwd: sending OSC bundles. + help files?
Iannis Zannos wrote: Thanks for all the replies. The svn download worked, so that is good enough for me at the moment. But I am not sure the plain osx download is the full version that you suggest. i am not sure what you mean by that. the link i gave you points to the authorative repository of mrpeach/osc (afaik); this means, that you cannot get a fuller version. however, the svn does not contain binaries (that is: the objects-files themselves) as these can be generated from the information provided. sorry if this is a bit too patronizing. fgmasdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] wiimote and OSCroute
philippe boisnard wrote: Hello there are many error. I tried with [OSCroute] and I have many error to. I can't create a patch that works good. a good start is to post these errors to the list. it's really complicated to deduce what is going on and help you from a generic term like there are errors. I tried to separate the data with unpack ([oscD] - [unpack]), but what is [oscD]? i don't know this object; it might be something like a double-precision [osc~] (sorry, i couldn't resist), or you might refer to [OSCdump], in which case i can only repeat myself: do not use the OSCx library; it is outdated, broken and unmaintained. I believe that, on mac, we don't have [packOSC] and [unpackOSC], isn't it ? how come? there is no bit of code in there that would prevent it from working on a mac. it is included in the general Pd-extended build system, so it should be there just fine. nevertheless it is part of the mrpeach/osc library; you might have to issue an [import mrpeach] first (or add mrpeach to the libraries loaded on startup) gfamsdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] 'pure' pd DSP abstractions wanted!
Jamie Bullock wrote: On Thu, 2008-08-28 at 04:09 +0200, [EMAIL PROTECTED] wrote: Quoting hard off [EMAIL PROTECTED]: jamie, my diy collection has no licence, no need for credit., etc.. i'm more than happy for you to do whatever and use it. each and every piece of software has a licence. just because you haven't manually assigned a license, doesn't mean that you have chosen the no licence option. snip That's true, content defaults to 'all rights reserved' by the copyright holder -- the content author unless a license is supplied explicitly . However, by emailing me and writing jamie, my diy collection has no licence, no need for credit., etc.. i'm more than happy for you to do whatever and use it. hard off is effectively supplying a license to me to use the software to do whatever I like. definitely; i just wanted to make sure that people know that they have to make their wish to share explicit in order to make it all work. it's a system of distrust, but its the system we live in. fgmasdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pasted objects now end up under the original object
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote: So, maybe, one should only paste to where the cursor is when the copy and paste are in the same window? But copy and paste in the same window is the same as Ctl-D, isn't it? For Ctl-D I think, the current solution which pastes with a little offset is quite convenient. Normally I move objects with the cursor keys then to keep nice alignments. I do think that pasted objects should get a z-index in front of the old objects, though, as often they are the objects that will get moved immediatly and pasting them behind existing objects makes it more likely to select one of the (now unselected) old objects and thus de-selecting the group of newly created objects. (I think, in pd-0.41 pasting is in front already or again. I don't remember if that was different in 0.40.) Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pasted objects now end up under the original object
Right, control-D should probably stay as it is, but separately copying and pasting migt want to do something smarter. I've always wanted to have Pd's behavior be absolutely independent of stacking order (back-to-front). Unfortunately, the way things look when Tk draws them depends on the order they're created in, which causes all sorts of confusion. THe current strategy for figuring out which object you clicked on is that, if more tan one object is selected, Pd prefers to drag an already-selected one; this is much better than whatever I had going before. cheers Miller On Mon, Sep 01, 2008 at 11:53:33AM +0200, Frank Barknecht wrote: Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote: So, maybe, one should only paste to where the cursor is when the copy and paste are in the same window? But copy and paste in the same window is the same as Ctl-D, isn't it? For Ctl-D I think, the current solution which pastes with a little offset is quite convenient. Normally I move objects with the cursor keys then to keep nice alignments. I do think that pasted objects should get a z-index in front of the old objects, though, as often they are the objects that will get moved immediatly and pasting them behind existing objects makes it more likely to select one of the (now unselected) old objects and thus de-selecting the group of newly created objects. (I think, in pd-0.41 pasting is in front already or again. I don't remember if that was different in 0.40.) Ciao -- Frank ___ 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] pasted objects now end up under the original object
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote: Right, control-D should probably stay as it is, but separately copying and pasting migt want to do something smarter. What about this idea/specification for a possible smart placement: 1) user presses Ctl-C and copies objects from coordinates (xc,yc) 2) user presses Ctl-V, mouse is at (xm, ym) 3) Objects get pasted at position: (xc, yc) - the original coordinates - but they don't get anchored yet. Now comes the new part: 4.1 a) If user moves the mouse now, the objects move to the mouse coordinates (xm, ym) and they stick to the mouse from that point on, until the next click. 4.1 b) Alternatively one could enter the sticky phase only if the user clicks the mouse, i.e. as soon as the user after step 3) clicks into the canvas, the objects move to the mouse position and stay selected for mouse movement until the button is released at which point the objects are anchored and possibly deselected. Deselecting could also require a second click. I like b) better than a): it contains less surprises. 4.2) This alternate path is taken, if the user doesn't use the mouse, but the cursor keys instead after step 3): The objects move relative to their new position at (xc, yc). They are still selected. Mouse movements don't affect their position anymore, mouse clicks will deselect the objects. That's basically the old, non-smart placement, which has its uses, too. THe current strategy for figuring out which object you clicked on is that, if more tan one object is selected, Pd prefers to drag an already-selected one; this is much better than whatever I had going before. Yes, that's good. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pasted objects now end up under the original object
Another possibility would be to use command-shift-paste to paste and immediately go into the stick state. I think I might have to try a few different ways to see which is most natural. M On Mon, Sep 01, 2008 at 01:09:49PM +0200, Frank Barknecht wrote: Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote: Right, control-D should probably stay as it is, but separately copying and pasting migt want to do something smarter. What about this idea/specification for a possible smart placement: 1) user presses Ctl-C and copies objects from coordinates (xc,yc) 2) user presses Ctl-V, mouse is at (xm, ym) 3) Objects get pasted at position: (xc, yc) - the original coordinates - but they don't get anchored yet. Now comes the new part: 4.1 a) If user moves the mouse now, the objects move to the mouse coordinates (xm, ym) and they stick to the mouse from that point on, until the next click. 4.1 b) Alternatively one could enter the sticky phase only if the user clicks the mouse, i.e. as soon as the user after step 3) clicks into the canvas, the objects move to the mouse position and stay selected for mouse movement until the button is released at which point the objects are anchored and possibly deselected. Deselecting could also require a second click. I like b) better than a): it contains less surprises. 4.2) This alternate path is taken, if the user doesn't use the mouse, but the cursor keys instead after step 3): The objects move relative to their new position at (xc, yc). They are still selected. Mouse movements don't affect their position anymore, mouse clicks will deselect the objects. That's basically the old, non-smart placement, which has its uses, too. THe current strategy for figuring out which object you clicked on is that, if more tan one object is selected, Pd prefers to drag an already-selected one; this is much better than whatever I had going before. Yes, that's good. Ciao -- Frank ___ 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] pasted objects now end up under the original object
Miller Puckette wrote: Another possibility would be to use command-shift-paste to paste and immediately go into the stick state. I think I might have to try a few different ways to see which is most natural. i am only glad that there are so few modifier keys on american keyboards. just imagine the possibilities we had with 9 different modifier keys (leaving the last finger for the modified key)...:-) anyhow, gmasdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] recirculating delay line reverberation time calculation
Hi all again, I think I found a reasonable solution, after reading around page 74 of this document: Introduction to Sound Processing by Davide Rocchesso http://profs.sci.univr.it/~rocchess/SP/sp.pdf 8 begin quote In practice, once we have constructed a lossless FDN prototype, we must insert attenuation coefficients and filters in the feedback loop. For instance, following the indications of Jot [45], we can cascade every delay line with a gain g_i = a^m_i // m_i is delay line length in samples This corresponds to replacing D(z) with D(z/a) in (42). With this choice of the attenuation coefficients, all the poles are contracted by the same factor a. As a consequence, all the modes decay with the same rate, and the reverberation time (defined for a level attenuation of 60dB) is given by Td = -3 Ts / log a // Ts is 1/samplerate 8 end quote That gives a different attenuation for each delay, but such that the decay per sample is constant for all of the delay lines, which makes the reverb time calculations much easier! gain_i = 10^(-3 * delay_i / reverbTime) where delay_i and reverbTime are measured in the same unit (eg: ms). Claude Miller Puckette wrote: hi all, I don't think anyone knows the answer to this. Traditionally, ever since Schroeder's reverberator, I think people have used delay times within a ratio of 1.5:1 of each other so that any old mean works OK. cheers Miller On Fri, Aug 29, 2008 at 10:07:30PM +0100, Claude Heiland-Allen wrote: Hi all, Referring to Miller's book [1], and having experimented with various delay times, I'm wondering what the average delay time used in the text is. If all the delay times are close to equal, then using the arithmetic mean as average gives me a reasonably accurate reverberation time calculation. But the more they differ the worse the result is (comparing with measurement against my implementation). [1] http://crca.ucsd.edu/~msp/techniques/latest/book-html/node111.html Intuitively it seems that the sound recirculates more often (and is thus attenuated more) through the shorter delay lines, but this is obviously not taken into account with arithmetic mean. I'm thinking something like harmonic mean might be better (but I tried it and it wasn't a huge improvement, nor was geometric mean). Any clarification would be enlightening, thanks, Claude -- http://claudiusmaximus.goto10.org ___ 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] pasted objects now end up under the original object
With Flash you copy using : command-c you paste in the center of your doc using : command-v you paste in place using : command-shift-v I like the command-d under Pd to duplicate because it is easy to align using shift-arrow keys. ++ Jack Le 1 sept. 08 à 13:17, Miller Puckette a écrit : Another possibility would be to use command-shift-paste to paste and immediately go into the stick state. I think I might have to try a few different ways to see which is most natural. M On Mon, Sep 01, 2008 at 01:09:49PM +0200, Frank Barknecht wrote: Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote: Right, control-D should probably stay as it is, but separately copying and pasting migt want to do something smarter. What about this idea/specification for a possible smart placement: 1) user presses Ctl-C and copies objects from coordinates (xc,yc) 2) user presses Ctl-V, mouse is at (xm, ym) 3) Objects get pasted at position: (xc, yc) - the original coordinates - but they don't get anchored yet. Now comes the new part: 4.1 a) If user moves the mouse now, the objects move to the mouse coordinates (xm, ym) and they stick to the mouse from that point on, until the next click. 4.1 b) Alternatively one could enter the sticky phase only if the user clicks the mouse, i.e. as soon as the user after step 3) clicks into the canvas, the objects move to the mouse position and stay selected for mouse movement until the button is released at which point the objects are anchored and possibly deselected. Deselecting could also require a second click. I like b) better than a): it contains less surprises. 4.2) This alternate path is taken, if the user doesn't use the mouse, but the cursor keys instead after step 3): The objects move relative to their new position at (xc, yc). They are still selected. Mouse movements don't affect their position anymore, mouse clicks will deselect the objects. That's basically the old, non-smart placement, which has its uses, too. THe current strategy for figuring out which object you clicked on is that, if more tan one object is selected, Pd prefers to drag an already- selected one; this is much better than whatever I had going before. Yes, that's good. Ciao -- Frank ___ 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-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] ssb tutorial patch
hi, it's labour day, and I am really bored :)), so I was wondering, does ssb stand for single sideband or signal sideband? the tutorial patch uses both, and a single sideband is always a signal sideband, or not?? just curious. thanks. marius. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ssb tutorial patch
Single sideband modulation. It comes from radio culture really. In the modulation schemes for analogue broadcast you havethe same spectral model with radio waves as we use for sound synthesis. But using up more bandwidth by having two sidebands is less desirable if you want to squeeze more channels into the same spectrum, so SSB was devised to minimise interference between stations. The tradeoff is that fewer sidebands mean less information is carried by the signal. If you research 'modulation' in a communications context you'll see a whole fascinating history of AM, quadrature, suppressed carrier, and other schemes. The SSB for frequency shifting in audio derives from the same idea in radio transmitter oscillators, to make copies of the sidebands 180 degree out of phase and mix them so that you end up with only one (upper or lower sideband). The Hilbert transform does this to a single sinusoid after generation, turning it into a complex signal (I forget what the mathematical word is, but it's really a sort of integration) Anyone know any novel or unusual patches for SSB. Presumably, for a single frequency you need only a fixed delay. a. On Mon, 01 Sep 2008 16:46:09 -0400 marius schebella [EMAIL PROTECTED] wrote: hi, it's labour day, and I am really bored :)), so I was wondering, does ssb stand for single sideband or signal sideband? the tutorial patch uses both, and a single sideband is always a signal sideband, or not?? just curious. thanks. marius. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Use the source ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pasted objects now end up under the original object
i think it's worth it to look at how some other applications handle it. it is quite annoying if the same function is different across applications and when you spent a lot of time in one program you get confused working with a different one. (for example i regularily try to go to edit mode in my PIM manager/address book with cmd-E and then remember that it is not pd) copy and pasting is an important part of pd. what is very confusing for beginners is that things are pasted exactly where they where in the first place. a typical situation is that someone has discovered a certain thing in an help-patch and wants to experiment with that. so the part is selected and a new window opened and pasted. nothing is drawn, so the student presses cmd-v some more times and later realizes that it all was pasted somewhere far off. i'd recommend that pasting pastes by default in the middle of the front window. cmd-alt-shift-v should do what the paste does now: paste to same position. that's how it is in adobe products by the way. ciao, max Am 01.09.2008 um 13:09 schrieb Frank Barknecht: Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote: Right, control-D should probably stay as it is, but separately copying and pasting migt want to do something smarter. What about this idea/specification for a possible smart placement: 1) user presses Ctl-C and copies objects from coordinates (xc,yc) 2) user presses Ctl-V, mouse is at (xm, ym) 3) Objects get pasted at position: (xc, yc) - the original coordinates - but they don't get anchored yet. Now comes the new part: 4.1 a) If user moves the mouse now, the objects move to the mouse coordinates (xm, ym) and they stick to the mouse from that point on, until the next click. 4.1 b) Alternatively one could enter the sticky phase only if the user clicks the mouse, i.e. as soon as the user after step 3) clicks into the canvas, the objects move to the mouse position and stay selected for mouse movement until the button is released at which point the objects are anchored and possibly deselected. Deselecting could also require a second click. I like b) better than a): it contains less surprises. 4.2) This alternate path is taken, if the user doesn't use the mouse, but the cursor keys instead after step 3): The objects move relative to their new position at (xc, yc). They are still selected. Mouse movements don't affect their position anymore, mouse clicks will deselect the objects. That's basically the old, non-smart placement, which has its uses, too. THe current strategy for figuring out which object you clicked on is that, if more tan one object is selected, Pd prefers to drag an already- selected one; this is much better than whatever I had going before. Yes, that's good. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list PGP.sig Description: Signierter Teil der Nachricht ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
