Quick [drunk] question...
Hi,
Just wondering what the equivalent to something like [drunk] or [urn] is for floats? I see these object convert all floats to ints.
Thanks,
brian
You could always use drunk or urn with a larger range, then divide by 100, or 1000, etc., depending on how much resolution you need.
Brian Heller wrote:
> Hi,
> Just wondering what the equivalent to something like [drunk] or [urn] is for floats? I see these object convert all floats to ints.
>
> Thanks,
> brian
>
[drunk 1000 10] -> [/ 999.]
i guess the equivalent for [urn] you will figure out yourself =)
p
On 26 sept. 08, at 10:02, pure wrote:
> Brian Heller wrote:
>> Hi,
>> Just wondering what the equivalent to something like [drunk] or
>> [urn] is for floats? I see these object convert all floats to ints.
>>
>> Thanks,
>> brian
>>
> [drunk 1000 10] -> [/ 999.]
> i guess the equivalent for [urn] you will figure out yourself =)
Although, remember that the first argument of drunk represent a range
and it is included (/ 1000. might be "better"), whereas the first
argument of urn is the number of random values therefore it's not
included (/ 999.).
ej
I use [f0.drunk] and [f0.rand]. I was hoping that floating point drunk and rand or urn would be incorporated into Max, but until then, I highly recommend checking out Fredrik Olofsson's externals and abstractions:
Also, Peter C. will be here shortly to recommend his indispensable Litter package...
Emmanuel Jourdan wrote:
> On 26 sept. 08, at 10:02, pure wrote:
>
>> Brian Heller wrote:
>>> Hi,
>>> Just wondering what the equivalent to something like [drunk] or
>>> [urn] is for floats? I see these object convert all floats to ints.
>>>
>>> Thanks,
>>> brian
>>>
>> [drunk 1000 10] -> [/ 999.]
>> i guess the equivalent for [urn] you will figure out yourself =)
>
> Although, remember that the first argument of drunk represent a range
> and it is included (/ 1000. might be "better"), whereas the first
> argument of urn is the number of random values therefore it's not
> included (/ 999.).
>
>
>
sloppy me! =)
For drunk I would use lp.zzz or lp.pfff or lp.pvvv or one of the other colored noise objects.
Drunk is a Brownian motion in the integer domain. Lp.pfff is Brownian motion in the real (floating point) domain.
Lp.pfff and lp.sss are in the Litter Starter Pack, the other Litter Power objects are in the Pro Bundle. URIs below.
--
For urn--Litter Power also has a more 'powerful' version (lp.ernie), but it is also in the integer domain. To be honest, the basic urn model doesn't make sense in the floating point domain. The urn model is that of a finite number of discrete possible "events". Any floating point domain is (approximately) infinite. So could you be more precise about what you want? If what you're after is a choice of several discrete floating point values, then you can combine ernie (or urn) with a trigger object. See patch below.
Hope this helps -- Peter
hm a float urn ...
say [urn 5.0]
how many floats does that give until its done...?
...
-mj
Quote: MJ wrote on Fri, 26 September 2008 21:23
----------------------------------------------------
> hm a float urn ...
> say [urn 5.0]
> how many floats does that give until its done...?
----------------------------------------------------
A bit over 2,000,000,000.
I realize the question was meant rhetorically, but it's a good exercise to work it out.
But hey! compared to the Bush/Bernake/Paulsen bailout, it ain't nuthin.
Thanks all! Great suggestions. Duh, not sure why I didn't just think of dividing. But it is strange that such a common object wouldn't have a float version included or accept them. Is there some clear benefit to that (other than some processing overhead, I suppose)? Just curious...
Thanks again,
Brian
Quote: Brian H. wrote on Sat, 27 September 2008 08:39
----------------------------------------------------
> Thanks all! Great suggestions. Duh, not sure why I didn't just think of dividing. But it is strange that such a common object wouldn't have a float version included or accept them. Is there some clear benefit to that (other than some processing overhead, I suppose)? Just curious...
----------------------------------------------------
Historically, Max was MIDI-oriented, and hence integer-oriented. Also, when Max was first developed, integers were significantly faster than floats on the CPUs available.
It's still not clear what you want from a "float urn". The animal doesn't make sense. Unless you can specify what you're after (which is probably not really a float urn) there's not going to be any headway.
In a similar vein, the way drunk implements Brownian motion is inherently integer-oriented. When I began work on Brownian noise for Litter Power, I actually built a plug-and-play float replacement following the model used by drunk, but found that it didn't work well. When I researched the literature about Brownian noise and related topics, I discovered algorithms that provide more satisfactory results, but were universes away from the range/step size model used by drunk.
If you can get what you want by simply dividing drunk's output by an arbitrary factor, let me go into rabbinic mode and ask what would the benefit be of building a "float drunk"? Aside from the image of an inebriated cherub wobbling erratically with well-oiled wings, which does admit a certain charm.
Hi,
OK Peter, I do see your point about [urn] as a float. For application at the moment, the specifics about the 'random' number aren't all that relevant-- Forget the [urn] thing and let's just say [random]. All I want to do is generate some random number within a given range to feed to [line] and then to [phasor~] for gain values-- Hence the need for floats. Your objects look great at first glance (need to glance again) and Chris' solution of dividing is just fine. I just figured it might be a fairly common need, and was surprised it wasn't 'officially' incorporated into Max.
Thanks again
Brian
Brian Heller schrieb:
> Hi, OK Peter, I do see your point about [urn] as a float. For
> application at the moment, the specifics about the 'random' number
> aren't all that relevant-- Forget the [urn] thing and let's just say
> [random].
I guess what you don't like about the normal random, that it put outs
values almost the same as the old value. You can test for that and then
retrigger random to replace it with something more tasty.
That's a general problem about good random, it doesn't have taste. Bad
random does, but it doesn't taste good. The art of algorithmic composing
is to create something which tastes good...
Cooking music in the end... ;-)
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com