hi,
more and more loving the new ``graph on parent'' feature, but still some doubts are in my mind.
- The conversion of an abstraction to a graph (to show up on parent)
is not persistent. This is because the flag is sent as part of
a coords' message, and#X coords' line is not being stored for
the main canvas (as it should not be).
Same for [table]s.
(Not so urgent) I do _not_ like being able to modify array
contents with a mouse (in performance mode), if this is an embedded array appearing on its parent (e.g. held in a [table]). This goes against a common practice of activating a ``pencil tool'' only when a waveform being edited is sufficiently zoomed-in. I would be happy to see the waveform's outline, having it protected from my hasty mouse.
Krzysztof
But, please don't make the solution to this problem be to disable editing of graphs in performance mode because i (and probably lots of other people) have patches that use this an important part of the interface.
On Wed, 30 Jan 2002 17:11:52 +0100 Krzysztof Czaja czaja@chopin.edu.pl wrote:
- (Not so urgent) I do _not_ like being able to modify array
contents with a mouse (in performance mode), if this is an embedded array appearing on its parent (e.g. held in a [table]). This goes against a common practice of activating a ``pencil tool'' only when a waveform being edited is sufficiently zoomed-in. I would be happy to see the waveform's outline, having it protected from my hasty mouse.
I agree. Spectral envelope drawing, anyone?
cheers Miller
On Wed, Jan 30, 2002 at 07:45:52PM +0100, pix wrote:
But, please don't make the solution to this problem be to disable editing of graphs in performance mode because i (and probably lots of other people) have patches that use this an important part of the interface.
On Wed, 30 Jan 2002 17:11:52 +0100 Krzysztof Czaja czaja@chopin.edu.pl wrote:
- (Not so urgent) I do _not_ like being able to modify array
contents with a mouse (in performance mode), if this is an embedded array appearing on its parent (e.g. held in a [table]). This goes against a common practice of activating a ``pencil tool'' only when a waveform being edited is sufficiently zoomed-in. I would be happy to see the waveform's outline, having it protected from my hasty mouse.
hm? yes, ...? marius
Am Mittwoch, 30. Januar 2002 20:08 schrieb Miller Puckette:
I agree. Spectral envelope drawing, anyone?
cheers Miller
On Wed, Jan 30, 2002 at 07:45:52PM +0100, pix wrote:
But, please don't make the solution to this problem be to disable editing of graphs in performance mode because i (and probably lots of other people) have patches that use this an important part of the interface.
On Wed, 30 Jan 2002 17:11:52 +0100
Krzysztof Czaja czaja@chopin.edu.pl wrote:
- (Not so urgent) I do _not_ like being able to modify array
contents with a mouse (in performance mode), if this is an embedded array appearing on its parent (e.g. held in a [table]). This goes against a common practice of activating a ``pencil tool'' only when a waveform being edited is sufficiently zoomed-in. I would be happy to see the waveform's outline, having it protected from my hasty mouse.
hi all,
Miller Puckette hat gesagt: // Miller Puckette wrote:
I agree. Spectral envelope drawing, anyone?
Yes, I'm playing with this. And while this is brought up, I have a probably simple question, which does bother me anyway:
Say I want to make an additive synthesis instrument, that generates its sound by an rifft~ object. This object should receive information about the magnitude of certain frequencies. This should be done with a (drawable) array, where the x axis is frequency and y is magnitude. The array gets read by a tabreceive~ and has a size = window blocksize. Now: How do I have to preprocess this xy-axis data to let rifft~ generate the matching sound composed of the input frequencies.
Any hints?
[I have some understanding of the FFT, but for this problem I just don't get a solution. Call me stupid.]
Ciao,
__ __
Frank Barknecht ____ ______ ____ __ trip\ \ / /wire ______
/ __// __ /__/ __// // __ \ / / __ \ ___\
/ / / ____/ / / / // ____// /\ \ ___\____ \
/_/ /_____/ /_/ /_//_____// / \ \_____\_____
/_/ _\
It's not the same approach, but there's a simple spectral-envelope-drawing example in
http://man104nfs.ucsd.edu/~mpuckett/172.01s/week1/
in 02_draw_spectrum.pd and the abstraction osc-voice.pd ... I'll think about cleaning it up to stick in the example patches.
Another possible approach is to use the envelope as a filter; rfft~ any signal, multiply right and left outputs by the "tabreceive", recombine via rifft~.
I don't think that directly synthesizing from the desired FFT spectrum will work very well, but you could try it by just sticking the tabreceive~ straight into the left-side input of the rifft~...
cheers Miller
On Wed, Jan 30, 2002 at 11:01:21PM +0100, Frank Barknecht wrote:
hi all,
Miller Puckette hat gesagt: // Miller Puckette wrote:
I agree. Spectral envelope drawing, anyone?
Yes, I'm playing with this. And while this is brought up, I have a probably simple question, which does bother me anyway:
Say I want to make an additive synthesis instrument, that generates its sound by an rifft~ object. This object should receive information about the magnitude of certain frequencies. This should be done with a (drawable) array, where the x axis is frequency and y is magnitude. The array gets read by a tabreceive~ and has a size = window blocksize. Now: How do I have to preprocess this xy-axis data to let rifft~ generate the matching sound composed of the input frequencies.
Any hints?
[I have some understanding of the FFT, but for this problem I just don't get a solution. Call me stupid.]
Ciao,
__ __Frank Barknecht ____ ______ ____ __ trip\ \ / /wire ______ / __// __ /__/ __// // __ \ / / __ \ ___\ / / / ____/ / / / // ____// /\ \ ___\____ \ /_/ /_____/ /_/ /_//_____// / \ \_____\_____
/_/ _\
hi i placed a spectral-filtering patch (and some others) at ftp://www.parasitaere-kapazitaeten.net/pdpatches marius.
Am Donnerstag, 31. Januar 2002 00:00 schrieb Miller Puckette:
It's not the same approach, but there's a simple spectral-envelope-drawing example in
http://man104nfs.ucsd.edu/~mpuckett/172.01s/week1/
in 02_draw_spectrum.pd and the abstraction osc-voice.pd ... I'll think about cleaning it up to stick in the example patches.
Another possible approach is to use the envelope as a filter; rfft~ any signal, multiply right and left outputs by the "tabreceive", recombine via rifft~.
I don't think that directly synthesizing from the desired FFT spectrum will work very well, but you could try it by just sticking the tabreceive~ straight into the left-side input of the rifft~...
cheers Miller
On Wed, Jan 30, 2002 at 11:01:21PM +0100, Frank Barknecht wrote:
hi all,
Miller Puckette hat gesagt: // Miller Puckette wrote:
I agree. Spectral envelope drawing, anyone?
Yes, I'm playing with this. And while this is brought up, I have a probably simple question, which does bother me anyway:
Say I want to make an additive synthesis instrument, that generates its sound by an rifft~ object. This object should receive information about the magnitude of certain frequencies. This should be done with a (drawable) array, where the x axis is frequency and y is magnitude. The array gets read by a tabreceive~ and has a size = window blocksize. Now: How do I have to preprocess this xy-axis data to let rifft~ generate the matching sound composed of the input frequencies.
Any hints?
[I have some understanding of the FFT, but for this problem I just don't get a solution. Call me stupid.]
Ciao,
__ __Frank Barknecht ____ ______ ____ __ trip\ \ / /wire ______ / __// __ /__/ __// // __ \ / / __ \ ___
/ / / ____/ / / / // ____// /\ \ ___\____
/_/ /_____/ /_/ /_//_____// / \ \_____\_____
/_/ _\
hi,
me too. The solution could be:
a) adding an explicit array property ``disable pencil''; b) as a), but used as a default when on parent; c) as a), but a default dependent on current zooming level (scaling); d) implicit handling: enable in array's window, disable on parent; e) as d), but zoom-dependent; f) ignoring...
Krzysztof
Miller Puckette wrote:
I agree. Spectral envelope drawing, anyone?
...
On Wed, Jan 30, 2002 at 07:45:52PM +0100, pix wrote:
But, please don't make the solution to this problem be to disable editing of graphs in performance mode because i (and probably lots of other people) have patches that use this an important part of the interface.
-
Frank Barknecht -
Krzysztof Czaja -
marius schebella -
Miller Puckette -
pix