hey folks, is it possible with abstractions to split control messages out of a [inlet~]? i've got a sound processing object which takes audio in and does some neat stuff to it when you bang it... it would make my whole perf. setup more consistant if i could take the bang + the audio in through the same inlet~... i guess i'm looking for a [route signal control] type object... any pointers?
hi Josh,
no, you would need numbered inlets, like those used in poly~ abstractions in Max. Otherwise, it would be hard to sort out control messages that are meant to feed tilde objects from those that are not (which is the case with regular inlets in Max).
Krzysztof
Josh Steiner wrote:
hey folks, is it possible with abstractions to split control messages out of a [inlet~]? i've got a sound processing object which takes audio
well there are objects like snapshot~ that take both type, so it seems to me (from my "never written a C pd object" perspective) that it should be possible to have an object with 1 inlet~, 1 outlet~ and 1 outlet that would split the inlet~ data according to its type. if a) this doesnt exist in some current form, or b) it not impossible do to something about the internals of pd i dont get, perhaps this would be a good first object for me to try
Krzysztof Czaja wrote:
hi Josh,
no, you would need numbered inlets, like those used in poly~ abstractions in Max. Otherwise, it would be hard to sort out control messages that are meant to feed tilde objects from those that are not (which is the case with regular inlets in Max).
Krzysztof
Josh Steiner wrote:
hey folks, is it possible with abstractions to split control messages out of a [inlet~]? i've got a sound processing object which takes audio
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
could you convert the control messsages to a signal that is in the range of original signal + 1 kinda thing, then use a high pass to get it back? kindof like a mux/demux?
On Wed, 2004-04-21 at 09:38, Josh Steiner wrote:
well there are objects like snapshot~ that take both type, so it seems to me (from my "never written a C pd object" perspective) that it should be possible to have an object with 1 inlet~, 1 outlet~ and 1 outlet that would split the inlet~ data according to its type. if a) this doesnt exist in some current form, or b) it not impossible do to something about the internals of pd i dont get, perhaps this would be a good first object for me to try
Krzysztof Czaja wrote:
hi Josh,
no, you would need numbered inlets, like those used in poly~ abstractions in Max. Otherwise, it would be hard to sort out control messages that are meant to feed tilde objects from those that are not (which is the case with regular inlets in Max).
Krzysztof
Josh Steiner wrote:
hey folks, is it possible with abstractions to split control messages out of a [inlet~]? i've got a sound processing object which takes audio
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
its a solution, but it wont work well for us because i want the performance system to be as consistant as possible so im not on stage scratchin my chin and thinking about which inlet does what. so i want all my abstractions first inlets to be action inlets, so for instance a sampler might take an audio signal and a 1/0 to turn sampling on off... i want to just plug an audio stream and a toggle into the first inlet instead of having to wrapperize the toggle to get it to work. its looking like i can't easily get what i want and am just going to have to have 1, 2, or 3 hot inlets depending on the object type (mono inlet~, mono inlet~ w/2nd hot control inlet, stereo inlet~, or stereo inlet~ w/3rd hot control inlet). of course being able to have tooltips on mouseover of an inlet like previously discussed here would make this less annoying, but for now i'm just going to have to be scratchin my chin...
Star Morin wrote:
could you convert the control messsages to a signal that is in the range of original signal + 1 kinda thing, then use a high pass to get it back? kindof like a mux/demux?
On Wed, 2004-04-21 at 09:38, Josh Steiner wrote:
well there are objects like snapshot~ that take both type, so it seems to me (from my "never written a C pd object" perspective) that it should be possible to have an object with 1 inlet~, 1 outlet~ and 1 outlet that would split the inlet~ data according to its type. if a) this doesnt exist in some current form, or b) it not impossible do to something about the internals of pd i dont get, perhaps this would be a good first object for me to try
Krzysztof Czaja wrote:
hi Josh,
no, you would need numbered inlets, like those used in poly~ abstractions in Max. Otherwise, it would be hard to sort out control messages that are meant to feed tilde objects from those that are not (which is the case with regular inlets in Max).
Krzysztof
Josh Steiner wrote:
hey folks, is it possible with abstractions to split control messages out of a [inlet~]? i've got a sound processing object which takes audio
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
Hi folks
i took IOhannes's advice and tried to build my own scalar with ..ewww Math. i succeed in getting the midi values to 6 to -5.99 is there a way to get it solidly form -6 to 6?
Patrick
Patrick Pagano,B.S. M.F.A candidate http://www.digitalworlds.ufl.edu http://www.screwmusicforever.com/SHREESWIFT
Here an abstraction (g_ramp.pd) that do what you want (it's shown in ramp.pd). you have to set 4 arguments : initial min, initial max, final min, final max.
Guillaume
Patrick wrote :
Hi folks
i took IOhannes's advice and tried to build my own scalar with ..ewww Math. i succeed in getting the midi values to 6 to -5.99 is there a way to get it solidly form -6 to 6?
Patrick
Patrick Pagano,B.S. M.F.A candidate http://www.digitalworlds.ufl.edu http://www.screwmusicforever.com/SHREESWIFT
Sorry, i forget the patch and abstraction...
Here an abstraction (g_ramp.pd) that do what you want (it's shown in ramp.pd). you have to set 4 arguments : initial min, initial max, final min, final max.
Guillaume
Patrick wrote :
Hi folks
i took IOhannes's advice and tried to build my own scalar with ..ewww Math. i succeed in getting the midi values to 6 to -5.99 is there a way to get it solidly form -6 to 6?
Patrick
on linux i have an object called : scale written by olaf (maxlib i think). i don't know what happen if you have gem install, cause there's also a object called scale in gem...
[number] | [scale 0 127 -6 6] | [print scale]
patrick
howdy -
i'm working on a 6 band eq, and was wondering if folks have any recommendations on a problem i'm having with it.
i use noise~ as the sound source, through 6 bp~'s (with frequency ranging from 60hz to 12k) through 6 *~'s w/ a range of 0-2. all of the "Q"s set to 20.
my problem is that 2 of my middle(ish) frequency bp~'s (800hz and 1k) are creating a distinctly noted sound... why is this? what would be considered "best practices" in creating a multi-band equalizer (q and frequency ranges, etc) in pd?
thanks!
ahhh - never mind (except the "best practices" part - i'm still totally interested in that ;)
i had a bad understanding of "q" (confusing "q" with bandwidth). i was set straight by this excellent guide: http://www.tonmeister.ca/main/textbook/electroacoustics/01.html
An inherent problem in this type of filter is commonly known of as "ringing." This is "the tendency of a filter to resonate at its natural frequency when excited by a sine wave pulse at that frequency." This effect is present to some extent in all equalizers but is of a low enough level to be masked by the remainder of the signal. It does, however, become excessive with filters with a high Q. At Q=0.5 the circuit does not ring and is said to be critically damped. Higher values of Q, however, will result in ringing for more cycles as the bandwidth becomes narrower.
On Wed, 2004-04-21 at 15:59, Star Morin wrote:
howdy -
i'm working on a 6 band eq, and was wondering if folks have any recommendations on a problem i'm having with it.
i use noise~ as the sound source, through 6 bp~'s (with frequency ranging from 60hz to 12k) through 6 *~'s w/ a range of 0-2. all of the "Q"s set to 20.
my problem is that 2 of my middle(ish) frequency bp~'s (800hz and 1k) are creating a distinctly noted sound... why is this? what would be considered "best practices" in creating a multi-band equalizer (q and frequency ranges, etc) in pd?
thanks!
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
AFAIK The Gem [scale] only works with Gem data. The maxlib [scale] is
the one you want. Its included with the packages but you'll probably
have to not load Gem in order to use it because of name conflicts. Or
use the alias [maxlib_scale].
.hc
On Wednesday, Apr 21, 2004, at 17:38 America/New_York, patrick wrote:
on linux i have an object called : scale written by olaf (maxlib i
think). i don't know what happen if you have gem install, cause there's also a
object called scale in gem...[number] | [scale 0 127 -6 6] | [print scale]
patrick
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
"Information wants to be free." -Stewart Brand
Hallo, Josh Steiner hat gesagt: // Josh Steiner wrote:
its a solution, but it wont work well for us because i want the performance system to be as consistant as possible so im not on stage scratchin my chin and thinking about which inlet does what. so i want all my abstractions first inlets to be action inlets, so for instance a sampler might take an audio signal and a 1/0 to turn sampling on off... i want to just plug an audio stream and a toggle into the first inlet instead of having to wrapperize the toggle to get it to work. its looking like i can't easily get what i want and am just going to have to have 1, 2, or 3 hot inlets depending on the object type (mono inlet~, mono inlet~ w/2nd hot control inlet, stereo inlet~, or stereo inlet~ w/3rd hot control inlet).
What I did in the RRADical patches is to reserve the rightmost inlet for OSC-messages. This makes that inlet another hot inlet, of course only for messages, but I can control everything I want through that inlet by just using various OSC messages. These messages are very easy to remember. They take their first path component out of the patch's first argument (or I just use * if I don'T care), all other arguments normally correspond to the visible controls, when using graph on parent.
Nevertheless, this allows me to get away with the smallest number of inlets: The rightmost one for OSC, all other for signals or special funtionality. To me, this turns out to be very consistent and easy to remember. Plus it's easy to build the OSC responders, as it's done automatically using the Memento system. Now I only still have to autobuild some /help-message that prints the active OSC paths to the console.
Ciao
Frank Barknecht _ ______footils.org__
-
Frank Barknecht -
guillaume -
Hans-Christoph Steiner -
Josh Steiner -
Krzysztof Czaja -
patrick -
Patrick Pagano -
Star Morin