The second outlet will eventually output the current filter bandwith, center, and gain, but right now it does nothing.
.hc
On Apr 9, 2012, at 2:39 PM, Samuel Burt wrote:
Hans,
Great to know. It works wonderfully with the beta of 0.43-extended here.
What is the second outlet of filterview?
I really appreciate the safeguards to prevent the filter from becoming unstable.
Sam
On Apr 9, 2012, at 11:13 , Hans-Christoph Steiner wrote:
The last bit is the key bit of information: filterview will only work on 0.43, not 0.42.5. It relies on some of the new features of 0.43.
.hc
On Apr 9, 2012, at 9:57 AM, Samuel Burt wrote:
Here are the steps I took:
I opened the help patch in the directory with the .pd_darwin binary file.
I turned on audio.
I selected a high pass filter.
I wondered if changing the bandwidth would do anything, so I moved my cursor over one of the red lines that show bandwidth. The line became highlighted but I could not move it from its position.
I selected a band pass filter.
I attempted to move the bandwidth, again, to no avail.
I single-clicked (no hold) in the area between the bandwidth markers and began changing the frequency of the band pass filter.
The filter continued following my pointer as long as it was inside the borders of the GUI.
If I moved my pointer out of the GUI and pressed command-E, the frequency would stop moving.
Pressing command-E, again, would resume following my pointer without my clicking anywhere.
Then, Pd failed with a spinning beach ball. A force quit was necessary.
In the meantime, when I clicked on the patch's titlebar, it showed one of the cursor symbols for changing the bandwidth.
Let me know if I can help test it more.
I suppose I left out one bit of information. I am running Pd-extended 0.42.5-extended.
Sam
On Apr 8, 2012, at 6:35 , Hans-Christoph Steiner wrote:
Hmm, I thought I got rid of that issue with it sticking to the mouse pointer... arg. Can you tell me the steps to reproduce it?
I should add more to the help patch. The goal was to make it as self-explanatory as possible. So you can click and move the filter center and gain, and click and drag on the vertical bandwidth lines to control the bandwidth.
.hc
On Apr 8, 2012, at 4:33 PM, Samuel Burt wrote:
Hans,
This is so exciting. The binary is working here on a MacIntosh 2.8 GHz Intel Core 2 Duo with OS 10.6.8. I thought you might appreciate some quick user feedback.
When I click the graphic, it lets me adjust frequency and amplitude, but then my cursor gets stuck to it like mouse up isn't working. Every time I click it adds another red vertical line.
A slight bit more documentation would be helpful in the help patch, too, explaining how one can interact with the graph with the mouse. Is it possible to change the bandwidth with the GUI? is there a key combination one can hold?
Sam
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
I've just taught myself about biquad~ and understand enough to know that a change in sampling rate will change the calculation of the center frequency. I was hoping the second outlet would output this information. Will it change based on the sampling rate or will it always be calculated for 44.1K?
Sam
On Apr 9, 2012, at 3:20 , Hans-Christoph Steiner wrote:
The second outlet will eventually output the current filter bandwith, center, and gain, but right now it does nothing.
.hc
On Apr 9, 2012, at 2:39 PM, Samuel Burt wrote:
Hans,
Great to know. It works wonderfully with the beta of 0.43-extended here.
What is the second outlet of filterview?
I really appreciate the safeguards to prevent the filter from becoming unstable.
Sam
On Apr 9, 2012, at 11:13 , Hans-Christoph Steiner wrote:
The last bit is the key bit of information: filterview will only work on 0.43, not 0.42.5. It relies on some of the new features of 0.43.
.hc
On Apr 9, 2012, at 9:57 AM, Samuel Burt wrote:
Here are the steps I took:
I opened the help patch in the directory with the .pd_darwin binary file.
I turned on audio.
I selected a high pass filter.
I wondered if changing the bandwidth would do anything, so I moved my cursor over one of the red lines that show bandwidth. The line became highlighted but I could not move it from its position.
I selected a band pass filter.
I attempted to move the bandwidth, again, to no avail.
I single-clicked (no hold) in the area between the bandwidth markers and began changing the frequency of the band pass filter.
The filter continued following my pointer as long as it was inside the borders of the GUI.
If I moved my pointer out of the GUI and pressed command-E, the frequency would stop moving.
Pressing command-E, again, would resume following my pointer without my clicking anywhere.
Then, Pd failed with a spinning beach ball. A force quit was necessary.
In the meantime, when I clicked on the patch's titlebar, it showed one of the cursor symbols for changing the bandwidth.
Let me know if I can help test it more.
I suppose I left out one bit of information. I am running Pd-extended 0.42.5-extended.
Sam
On Apr 8, 2012, at 6:35 , Hans-Christoph Steiner wrote:
Hmm, I thought I got rid of that issue with it sticking to the mouse pointer... arg. Can you tell me the steps to reproduce it?
I should add more to the help patch. The goal was to make it as self-explanatory as possible. So you can click and move the filter center and gain, and click and drag on the vertical bandwidth lines to control the bandwidth.
.hc
On Apr 8, 2012, at 4:33 PM, Samuel Burt wrote:
Hans,
This is so exciting. The binary is working here on a MacIntosh 2.8 GHz Intel Core 2 Duo with OS 10.6.8. I thought you might appreciate some quick user feedback.
When I click the graphic, it lets me adjust frequency and amplitude, but then my cursor gets stuck to it like mouse up isn't working. Every time I click it adds another red vertical line.
A slight bit more documentation would be helpful in the help patch, too, explaining how one can interact with the graph with the mouse. Is it possible to change the bandwidth with the GUI? is there a key combination one can hold?
Sam
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
It understands the global sample rate, but not yet the sample rate set with [block~].
.hc
On Apr 9, 2012, at 3:28 PM, Samuel Burt wrote:
I've just taught myself about biquad~ and understand enough to know that a change in sampling rate will change the calculation of the center frequency. I was hoping the second outlet would output this information. Will it change based on the sampling rate or will it always be calculated for 44.1K?
Sam
On Apr 9, 2012, at 3:20 , Hans-Christoph Steiner wrote:
The second outlet will eventually output the current filter bandwith, center, and gain, but right now it does nothing.
.hc
On Apr 9, 2012, at 2:39 PM, Samuel Burt wrote:
Hans,
Great to know. It works wonderfully with the beta of 0.43-extended here.
What is the second outlet of filterview?
I really appreciate the safeguards to prevent the filter from becoming unstable.
Sam
On Apr 9, 2012, at 11:13 , Hans-Christoph Steiner wrote:
The last bit is the key bit of information: filterview will only work on 0.43, not 0.42.5. It relies on some of the new features of 0.43.
.hc
On Apr 9, 2012, at 9:57 AM, Samuel Burt wrote:
Here are the steps I took:
I opened the help patch in the directory with the .pd_darwin binary file.
I turned on audio.
I selected a high pass filter.
I wondered if changing the bandwidth would do anything, so I moved my cursor over one of the red lines that show bandwidth. The line became highlighted but I could not move it from its position.
I selected a band pass filter.
I attempted to move the bandwidth, again, to no avail.
I single-clicked (no hold) in the area between the bandwidth markers and began changing the frequency of the band pass filter.
The filter continued following my pointer as long as it was inside the borders of the GUI.
If I moved my pointer out of the GUI and pressed command-E, the frequency would stop moving.
Pressing command-E, again, would resume following my pointer without my clicking anywhere.
Then, Pd failed with a spinning beach ball. A force quit was necessary.
In the meantime, when I clicked on the patch's titlebar, it showed one of the cursor symbols for changing the bandwidth.
Let me know if I can help test it more.
I suppose I left out one bit of information. I am running Pd-extended 0.42.5-extended.
Sam
On Apr 8, 2012, at 6:35 , Hans-Christoph Steiner wrote:
Hmm, I thought I got rid of that issue with it sticking to the mouse pointer... arg. Can you tell me the steps to reproduce it?
I should add more to the help patch. The goal was to make it as self-explanatory as possible. So you can click and move the filter center and gain, and click and drag on the vertical bandwidth lines to control the bandwidth.
.hc
On Apr 8, 2012, at 4:33 PM, Samuel Burt wrote:
> Hans, > > This is so exciting. The binary is working here on a MacIntosh 2.8 GHz Intel Core 2 Duo with OS 10.6.8. I thought you might appreciate some quick user feedback. > > When I click the graphic, it lets me adjust frequency and amplitude, but then my cursor gets stuck to it like mouse up isn't working. Every time I click it adds another red vertical line. > > A slight bit more documentation would be helpful in the help patch, too, explaining how one can interact with the graph with the mouse. Is it possible to change the bandwidth with the GUI? is there a key combination one can hold? > > Sam > >
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
On 04/09/12 23:59, Hans-Christoph Steiner wrote:
It understands the global sample rate, but not yet the sample rate set with [block~].
while i haven't looked at the object yet (though it sounds very useful), i would like to suggest adding a message that forces filter coefficients to be calculated for a certain samplerate.
e.g. [samplerate 8000(
which would override the default (which is to take the subpatches samplerate (as set by [block~])
fgmadsr IOhannes
On Apr 10, 2012, at 1:06 AM, IOhannes m zmölnig wrote:
On 04/09/12 23:59, Hans-Christoph Steiner wrote:
It understands the global sample rate, but not yet the sample rate set with [block~].
while i haven't looked at the object yet (though it sounds very useful), i would like to suggest adding a message that forces filter coefficients to be calculated for a certain samplerate.
e.g. [samplerate 8000(
which would override the default (which is to take the subpatches samplerate (as set by [block~])
Why not just make it respect the [block~] settings?
.hc
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
Le 10/04/2012 16:05, Hans-Christoph Steiner a écrit :
On Apr 10, 2012, at 1:06 AM, IOhannes m zmölnig wrote:
On 04/09/12 23:59, Hans-Christoph Steiner wrote:
It understands the global sample rate, but not yet the sample rate set with [block~].
while i haven't looked at the object yet (though it sounds very useful), i would like to suggest adding a message that forces filter coefficients to be calculated for a certain samplerate.
e.g. [samplerate 8000(
which would override the default (which is to take the subpatches samplerate (as set by [block~])
Why not just make it respect the [block~] settings?
i think making it to respect [block~] setting is very important to this object, but having possibility to set an other samplerate would allow other utilisation : it could then be also use to compute filter coefficient for pix_biquad by example.
c
.hc
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Apr 10, 2012, at 10:14 AM, Cyrille Henry wrote:
Le 10/04/2012 16:05, Hans-Christoph Steiner a écrit :
On Apr 10, 2012, at 1:06 AM, IOhannes m zmölnig wrote:
On 04/09/12 23:59, Hans-Christoph Steiner wrote:
It understands the global sample rate, but not yet the sample rate set with [block~].
while i haven't looked at the object yet (though it sounds very useful), i would like to suggest adding a message that forces filter coefficients to be calculated for a certain samplerate.
e.g. [samplerate 8000(
which would override the default (which is to take the subpatches samplerate (as set by [block~])
Why not just make it respect the [block~] settings?
i think making it to respect [block~] setting is very important to this object, but having possibility to set an other samplerate would allow other utilisation : it could then be also use to compute filter coefficient for pix_biquad by example.
I agree entirely, but I have run out of time to work on this for a long while. Patches and forks are welcome, and I'll try to make the time to integrate people's work into this one. There is a lot this object could do, including having a logarithmic scale for frequency (its linear now).
Another idea is to make it into a library that includes all of the biquad calc objects from ggee, then the math functions written in C could be used for the GUI calcs too, making it faster. They could be written as signal objects also, so we'd have [bandpass] and [bandpass~], etc. Then it would need to include a version of [biquad~] that had 5 signal inlets for the 5 coefficients at signal rate.
.hc
"It is convenient to imagine a power beyond us because that means we don't have to examine our own lives.", from "The Idols of Environmentalism", by Curtis White
Le 10/04/2012 17:03, Hans-Christoph Steiner a écrit :
Then it would need to include a version of [biquad~] that had 5 signal inlets for the 5 coefficients at signal rate.
yes, that would be very nice.
i somehow regret that my bq~ object is not compatible with vanilla biquad~.
C
.hc
"It is convenient to imagine a power beyond us because that means we don't have to examine our own lives.", from "The Idols of Environmentalism", by Curtis White
On Apr 10, 2012, at 11:08 AM, Cyrille Henry wrote:
Le 10/04/2012 17:03, Hans-Christoph Steiner a écrit :
Then it would need to include a version of [biquad~] that had 5 signal inlets for the 5 coefficients at signal rate.
yes, that would be very nice.
i somehow regret that my bq~ object is not compatible with vanilla biquad~.
You could take filterview and make bqview. The new library template makes it much easier to share C code. If you split out the various coeff calcs for the different filter types into individual, generic C functions, then put them all in libnusmuk-audio.c, it'll automatically get built into a shared library and all the objects linked to it (if you are using the most up-to-date Makefile).
Then those C functions can be made into Tcl procs, and you can replace the pure Tcl procs in filterview.tcl for doing the coeff calc.
.hc
kill your television
Le 10/04/2012 17:14, Hans-Christoph Steiner a écrit :
On Apr 10, 2012, at 11:08 AM, Cyrille Henry wrote:
Le 10/04/2012 17:03, Hans-Christoph Steiner a écrit :
Then it would need to include a version of [biquad~] that had 5 signal inlets for the 5 coefficients at signal rate.
yes, that would be very nice.
i somehow regret that my bq~ object is not compatible with vanilla biquad~.
You could take filterview and make bqview. The new library template makes it much easier to share C code. If you split out the various coeff calcs for the different filter types into individual, generic C functions, then put them all in libnusmuk-audio.c, it'll automatically get built into a shared library and all the objects linked to it (if you are using the most up-to-date Makefile).
Then those C functions can be made into Tcl procs, and you can replace the pure Tcl procs in filterview.tcl for doing the coeff calc.
well, there is no need for 2 almost similar object. i will certainlly depreciate bq~ once a better replacement is made...
by the way, why are you doing the work for biquad~ since you already know that it must be change to include 5 audio inlet (like bq~)? The bq~ structure look more popular than biquad~ structure. And i read somwhere that it's structure is more stable for low frequency.
why not using bq~ better than biquad~?
c
.hc
kill your television
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Apr 10, 2012, at 11:43 AM, Cyrille Henry wrote:
Le 10/04/2012 17:14, Hans-Christoph Steiner a écrit :
On Apr 10, 2012, at 11:08 AM, Cyrille Henry wrote:
Le 10/04/2012 17:03, Hans-Christoph Steiner a écrit :
Then it would need to include a version of [biquad~] that had 5 signal inlets for the 5 coefficients at signal rate.
yes, that would be very nice.
i somehow regret that my bq~ object is not compatible with vanilla biquad~.
You could take filterview and make bqview. The new library template makes it much easier to share C code. If you split out the various coeff calcs for the different filter types into individual, generic C functions, then put them all in libnusmuk-audio.c, it'll automatically get built into a shared library and all the objects linked to it (if you are using the most up-to-date Makefile).
Then those C functions can be made into Tcl procs, and you can replace the pure Tcl procs in filterview.tcl for doing the coeff calc.
well, there is no need for 2 almost similar object. i will certainlly depreciate bq~ once a better replacement is made...
by the way, why are you doing the work for biquad~ since you already know that it must be change to include 5 audio inlet (like bq~)? The bq~ structure look more popular than biquad~ structure. And i read somwhere that it's structure is more stable for low frequency.
why not using bq~ better than biquad~?
I know biquad~, that's the only reason. I'll leave it to others to debate which is the best approach to implementing a biquad filter.
.hc
c
.hc
kill your television
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams