Re: [PD] reverb for each grain
Sounds fun Are you using the [nqpoly4] object to make the granular engine? S On 30 Jan 2008, at 06:59, Kevin McCoy wrote: > Not to mention, I hope you'll be showin' some clips of whatever you > come up with... doing something like this is something I have had in > mind for a while and I would love to hear the results you get! Are > you thinking it can make the grain cloud more "dimensional" this way? > That was the idea I had.. > > km > > On Jan 30, 2008 1:06 AM, hard off <[EMAIL PROTECTED]> wrote: >> well, as charles suggested, set up a few different reverbs of varying >> decay lengths, and send varying percentages of each grain to the >> different reverbs. >> >> also, reverb usually has a 'dampening' setting, which will dull the >> signal as it goes through, so another thing you can try is to mix >> in a >> lowpass or bandpass filter after every voice before it goes in to the >> reverb. if you alter the dry/wet ratio of each voice going into the >> filter, as well as altering the cutoff and q values for each filter >> it >> will make it sound similar to if each voice were going through a >> different reverb. >> >> >> ___ >> PD-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> > > > > -- > > > http://art.sewanee.edu/mccoy > > ___ > 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] one more boring computation-time cuestion of mine...
2008/1/29, Charles Henry <[EMAIL PROTECTED]>: > Another diagnostic idea: try comparing the behavior during loading > with audio switched on and off. Whops, I hadn't thought about that :$ Thank you :) > my guess is: > if this is a memory issue, it won't make a difference > if it's the computations involved with big #'s of tabplay~, then it > will be faster with audio off Ye! I reverted (temporarily) to the version with many tabplays, and indeed: with audio off it is much faster, about as fast as the version without tabplays. So it is definitely not a memory issue. Now, out of mere insane curiosity, I made the following test: In the "sample" abstraction, I replaced this: [table $1] ... [tabplay~ $1] with this: [table $1] ... [tabplay~] I tried the load with audio on, and surprise! I get the same speedup as removing tabplay~s or switching off audio! So the fact that the tabplays are "linked" to tables (or viceversa) is definitely relevant. > > Chuck > > On Jan 29, 2008 1:21 PM, Matteo Sisti Sette <[EMAIL PROTECTED]> wrote: > > > > > Just a guess... maybe allocating all that memory is forcing the OS to > > > page other apps out. > > > > I can't discard that, but... > > Correct me if I am wrong: if that was the case, removing the [tabplay~]s > > shouldn't make a difference, should it? > > > > I removed the tabplay~s but the number of tables and size of the sound > > samples are the same, and now it loads all samples much much faster. > > > > To "rephrase" the whole problem in a simpler way, consider this: > > > > A) N occurrences of: > > [table table-K][soundfiler] > > > > [tabplay~ table-K] > > > > (with K=1,2,...,N) > > > > Versus this: > > > > B) N occurrences of just [table table-K] and [soundfiler] > > and only one unique [tabplay~]. > > > > When I "load" samples, each soundfiler receives a > > [read -resize something.wav table-K( message. > > > > In case (A) loading all samples is much slower. > > > > > > My guess was the following: > > "Every time a soundfiler loads a file into an array, and therefore resizes > > it, the DSP graph (or SOMETHING) is recomputed. In PD's data structures, for > > some reason each table has some sort of link to any [tabplay~] or [tabread~] > > object "attached" to it (in this case one tabplay per table). So when > > recomputing the whole data structure (once per table resize) there's some > > kind of operation that is being done N times in case A and zero or one times > > in case B." > > > > Or maybe the first part is correct and the second part is much > > simpler?: > > "Evert time a soundfiler loads a file into an array, and therefore resizes > > it, the DSP graph is recomputed, and the time needed to do this is > > proportional to the number of existing "~" objects. Therefore removing a > > big number of useless [tabplay~]s is reducing the size of the graph and time > > needed to calculate it." > > > > > > Is any of my two guesses even near to correct? > > > > Thanks a lot > > m. > > > > > > > > On Mon, Jan 28, 2008 at 04:52:56PM +0100, matteo sisti sette wrote: > > > Hi, > > > > > > Suppose I create a [sample] abstraction that basically contains a > > > [table] to store a sound sample, and a [soundfiler] to read it from a > > > file. > > > > > > One of the reasons for creating such a "trivial" abstraction is that > > > it has a GOP GUI with > > > -a symbolbox where you can write and see the filename > > > -a test button that plays the sample. > > > > > > Now suppose the test part is implemented like this (simplified): > > > > > > [r $1-test] > > > | > > > [tabplay~ $1] > > > | > > > [throw~ sampletestout] > > > > > > > > > ($1 is the name of the sample, i.e. the name of the table, and the GUI > > > is supposed to have a bng sending to $1-test) > > > > > > Obviously, to avoid unnecessary cpu-usage, that would become enormous > > > if I have many sample instances, I will include the necessary patching > > > in the abstraction in order to [switch~] it on only when playing, and > > > off when not. Usually you'll be testing at most one sample at the same > > > time. > > > > > > Now the question is: in case there are N [sample]s in my patch, > > > Is it possible that the time needed to load ONE sample (sending a > > > [read...( message to the [soundfiler]) increases with N??? > > > If so, why? > > > > > > The fact is that I have been using such an abstraction very much, and > > > have a great number of [sample]s in my patch, and started to notice > > > that loading all the samples was terribly slow. > > > Then, without thinking it had any relation to this, I realised I could > > > easily remove all the "~" part from the sample abstraction, by > > > implementing a unique [sampletester] and having [sample]s sending him > > > messages to test one sample. > > > I did this, and removed the [tabplay~] thing from the [sample] > > > abstraction, and now the loading of samples seems to be enormously > > > faster... > > > > > > > > > > > > --
Re: [PD] pdlua output
robcanning wrote: > now i want to be able to send the message [greaterthan score 3( > > so in the code where it says "score=(%d+)")) - i need "score" to be > variable from second part of the message the ">1" needs to be a > variable from the 3rd part of the message The Lua operator .. is string concatenation, so you can do: "foo" .. "bar" to get: "foobar" > i know its somewhere within the () below but i cant seem to get it right > function M:in_1_greaterthan() > > thanks, > > rob c Something like: -- called when "greaterthan" message is received at first inlet -- atoms is a table of the atoms in the message following the selector function M:in_1_greaterthan(atoms) local name = atoms[1] -- could be: "score" local value = atoms[2] -- could be: 3 if name ~= nil and value ~= nil then -- could check types too.. -- do your stuff here end end If you have a range of possible selectors, and don't want to have to write a method for all of them, you can use: function M:in_1(selector, atoms) ... end Then selector will be "greaterthan" (or whatever) and atoms will be as above. More specific methods are called before less specific methods, read pd.lua to see how that works (it's in the dispatcher function(s)). Hope this helps, Claude -- http://claudiusmaximus.goto10.org ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdlua output
Frank Barknecht wrote:
> Hallo,
> robcanning hat gesagt: // robcanning wrote:
>
>
>> i add a list to a table with:
>>
>> -- "insert [list]" into 1st inlet:
>> function M:in_1_insert(list)
>>table.insert(self.mydata, list)
>> end
>>
>> then i search the table for the pattern "score = 1" and ask it to print
>> the lines containing the matched pattern
>>
>> -- what to do on "scores" into 1st inlet:
>> function M:in_1_scores()
>> for i, v in ipairs(self.mydata) do
>> if string.match(v, "score = 1", 1, true) then
>> self:outlet(1, "list", v) end
>> end
>> end
>>
>> the problem is that the string.match is expecting a string and getting a
>> table and i'm not sure how to fix this - i thought the ipairs was
>> iterating the table into a string but its not.
>>
>> here is the error from pd:
>> [string "rob2"]:19: bad argument #1 to 'match' (string expected, got table)
>>
>
> Okay, that's an issue with the general kinds of types in Lua, which
> can be a bit confusing at first. Basically in Lua/Pd you will have to
> deal with these three types: numbers, strings and tables. (There are
> more types e.g. functions.)
>
> Now the first two are easy: numbers are 1, 2, 3.141, ... and strings
> are "this" and "that, too". Tables however are a bit trickier: For one
> they can be like lists in Pd:
>
> counts = {1, 2, 3, "four", "and five"}
> print(counts[4]) -- prints: "four"
> print(type(counts[4])) -- it's a string
>
> These kinds of tables which are indexed with numbers are also called
> "arrays" in Lua parlance. In Pd they are called lists.
>
> Arrays also can contain other arrays and tables:
>
> counts = {1, 2, 3, "four", "and five",
> {"x", "y", "z"}
> }
>
> But the outlet functions in pdlua generally only work with flat
> arrays! So you first need to convert your data to a flat array using a
> pairs/ipairs iterator for example.
>
> In the "in_*_something(args)" methods, args generally is an array as
> well (except for the bang, float and symbol methods).
>
> The self.mydata table in rob2.lua is not flat, so it needs to be made
> flat like that.
>
> self.mydata also is a key/value table (containing flat arrays indexed
> by string or numeric keys).
>
> Tables in Lua can be key/value containers, which is something, Pd
> doesn't have directly:
>
> veggies = {apples = 4, potatoes = 10}
> print(veggies.apples) -- prints: 4
>
> And to make things worse, tables can contain tables:
>
> stuff = {counts, veggies}
> print(stuff[2].potatoes) -- prints: 10
>
> or even stuff like functions:
>
> stuff.func = function()
> -- does nothing
> end
>
> for k,v in pairs(stuff) do
> print (k,v)
> end
>
> So, you see in that part here:
>
> for i, v in ipairs(self.mydata) do
> if string.match(v, "score = 1", 1, true) then
> self:outlet(1, "list", v)
> end
> end
>
> You have one "v" which is expected to be a string in string.match(),
> and another which is expected to be a table/array in self:outlet()!
>
> This won't work, and the error message of Lua tells you, that "v" (the
> values of self.mydata) is a table, so it won't work in string.match()
>
> I hope this clears it up a bit.
>
> Now for the fix: You can convert a (flat) list/array to a string with
> table.concat(somelist, sep) where sep is the separator. If you use a
> space for sep, you can use
>
> string.match(table.concat(v, " "), "score = 1")
>
> or a bit better:
>
> string.find(table.concat(v, " "), "score = 1", 1, true)
>
> Better because string.find doesn't try to build and return a string,
> which you wouldn't be interested in anyhow.
>
> Ciao
>
>
ok great - i got the hang of that now i think
now what i cant figure out is how to pass arguments to the code from a
pd message
ok, so this code finds all the scores with a value greater than one and
sends them to outlet one when given the message [greaterthan(
function M:in_1_greaterthan()
for i, v in ipairs(self.mydata) do
if tonumber(string.match(table.concat(v, " "), "score=(%d+)")) > 1
then self:outlet(1, "", v) end
end
end
now i want to be able to send the message [greaterthan score 3(
so in the code where it says "score=(%d+)")) - i need "score" to be
variable from second part of the message the ">1" needs to be a
variable from the 3rd part of the message
i know its somewhere within the () below but i cant seem to get it right
function M:in_1_greaterthan()
thanks,
rob c
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdlua output
Hallo, robcanning hat gesagt: // robcanning wrote: > ok, so this code finds all the scores with a value greater than one and > sends them to outlet one when given the message [greaterthan( > > > function M:in_1_greaterthan() > for i, v in ipairs(self.mydata) do > if tonumber(string.match(table.concat(v, " "), "score=(%d+)")) > 1 > then self:outlet(1, "", v) end > end > end > > now i want to be able to send the message [greaterthan score 3( > > so in the code where it says "score=(%d+)")) - i need "score" to be > variable from second part of the message the ">1" needs to be a > variable from the 3rd part of the message > > i know its somewhere within the () below but i cant seem to get it right > function M:in_1_greaterthan() Okay, now function M:in_1_greaterthan() needs to accept additional data. This gets passed as an argument to the function. Arguments are wrapped in a table in pdlua. In the following I called that table "args", but you can call it anything. Then "args" is concatenated into a single search string. function M:in_1_greaterthan(args) searchstring = table.concat(args, " ") for i, v in ipairs(self.mydata) do if tonumber(string.match(table.concat(v, " "), searchstring)) > 1 then self:outlet(1, "", v) end end end Ciao -- Frank Barknecht _ __footils.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdlua output
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote: > function M:in_1_greaterthan(args) > searchstring = table.concat(args, " ") > for i, v in ipairs(self.mydata) do >if tonumber(string.match(table.concat(v, " "), searchstring)) > 1 > then self:outlet(1, "", v) end > end > end Ah, this is in part bulls**t, better check out Claude's solution. I misread your goal a bit. Ciao -- Frank Barknecht _ __footils.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdlua output
Hallo,
Claude Heiland-Allen hat gesagt: // Claude Heiland-Allen wrote:
> Something like:
>
> -- called when "greaterthan" message is received at first inlet
> -- atoms is a table of the atoms in the message following the selector
> function M:in_1_greaterthan(atoms)
>local name = atoms[1] -- could be: "score"
>local value = atoms[2] -- could be: 3
>if name ~= nil and value ~= nil then -- could check types too..
> -- do your stuff here
>end
> end
>
>
> If you have a range of possible selectors, and don't want to have to
> write a method for all of them, you can use:
>
> function M:in_1(selector, atoms) ... end
>
> Then selector will be "greaterthan" (or whatever) and atoms will be as
> above.
One thing I wanted to ask here: Is there a special reason that pdlua
isn't using the (new in 5.1) vararg syntax with "..." for methods and
maybe also in outlet(...) or similar places? Then it would be possible
to just do self:outlet(outnum, sel, a, b, c) instead of having to pack it
first like self:outlet(outnum, sel, {a,b,c}). And for things like
bang-output, it could be even simpler: self:outlet(outnum, "bang")
instead of: self:outlet(outnum, "bang", {})
Ciao
--
Frank Barknecht _ __footils.org__
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdlua output
Frank Barknecht wrote: > One thing I wanted to ask here: Is there a special reason that pdlua > isn't using the (new in 5.1) vararg syntax with "..." for methods and > maybe also in outlet(...) or similar places? Yes. It makes it very difficult to do useful things with variable length inputs (such as iterating over them, storing them, etc). See for example: http://lua-users.org/wiki/VarargTheSecondClassCitizen Claude -- http://claudiusmaximus.goto10.org ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] fun with telephone sounds
On Jan 29, 2008 8:25 PM, Hans-Christoph Steiner <[EMAIL PROTECTED]> wrote: > > For some reason, I just reproduced some standard telephone sounds in > Pd... maybe these exist somewhere already, but I thought I'd post > this for fun. > Neat. :) On the same topic, here is a nice reference for standard telephony tones by country, published by the ITU: http://www.itu.int/ITU-T/inr/forms/files/tones-0203.pdf -- Russell Bryant ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
