Oops.. that's a bug.
To work around it for now, add 1 (or a higher integer), then wrap...
cheers
Miller
On Mon, May 07, 2007 at 09:40:53PM +0200, Steffen wrote:
>
> On 07/05/2007, at 20.51, Claude Heiland-Allen wrote:
> > Note: 0 -> [wrap~] -> 1, which is weird (and undesirable in my eyes).
>
>
On 07/05/2007, at 20.51, Claude Heiland-Allen wrote:
> Note: 0 -> [wrap~] -> 1, which is weird (and undesirable in my eyes).
Yeah. I still can't translate "wrap~ gives the difference between the
input and the largest integer not exceeding it" to that. The quote is
from the help file.
I fixed it so it works. Solution is attached. If you are interested in
samplers, loading multiple samples, having smooth loop points, sending
to multiple targets, etc, you should also check out the "sample"
section of the pdmtl abstractions:
http://wiki.dataflow.ws/PdMtlAbstractions/Contents#head-
HI IOhannes,
thanks, yes, I found the difference! I think I was trying to wrap around
the length of the loop instead of the length of the table (for some
reason or another...). The patch you sent does exactly what I set out to
do, and essentially is only different in this way. So it wasn't [wra
Derek Holzer wrote:
Yes, correct. If I have a table that's 100 places long, and I set the
offset to 95 and the length to 30, I would like to get a loop that
starts at 95 and when it reaches 100, continue playing at 0 up to 25.
The next loop would then begin again at 95 and wrap around through 0
Hi there,
I am not so terribly into that right now..
Just an idea.
What if you just shift the table and write it to a second one...
silly probably...
just an idea
Am 07.05.2007 um 20:25 schrieb Derek Holzer:
> Sorry! Should read:
>
> Yes, correct. If I have a table that's 100 places long, an
IOhannes m zmoelnig wrote:
> Derek Holzer wrote:
>> Hi Roman,
>>
>> and thanks. I implemented it in my patch, but it doesn't seem to work
>> right. The looping isn't seamless, in fact there's a "hiccup" at the
>> point where the loop wraps around. In my previous version, I had another
>> function t
Derek Holzer wrote:
> Hi Roman,
>
> and thanks. I implemented it in my patch, but it doesn't seem to work
> right. The looping isn't seamless, in fact there's a "hiccup" at the
> point where the loop wraps around. In my previous version, I had another
> function to calculate the offset and start p
Sorry! Should read:
Yes, correct. If I have a table that's 100 places long, and I set the
offset to 95 and the length to 30, I would like to get a loop that
starts at 95 and when it reaches 100, continue playing at 0 up to 25.
The next loop would then begin again at 95 and wrap around through 0
Yes, correct. If I have a table that's 100 places long, and I set the
offset to 95 and the length to 25, I would like to get a loop that
starts at 95 and when it reaches 100, continue playing at 0 up to 25.
The next loop would then begin again at 95 and wrap around through 0 to
25, und so weite
Hallo,
Frank Barknecht hat gesagt: // Frank Barknecht wrote:
> Hallo,
> Derek Holzer hat gesagt: // Derek Holzer wrote:
>
> > Test patch attached... see the [wraparound~] subpatch for the part which
> > doesn't work yet!
>
> I added a [tabread4~ test_zample] and now it works. ;)
>
> Now serio
Hi Frank,
thanks for helping. This is the solution I tried at first. However, with
this every loop starts at the beginning of the table, no matter where I
set the loop offset. I'm assuming you actually tested it before posting,
so are there different versions of [wrap~] perhaps?
d.
Frank Bark
Hallo,
Derek Holzer hat gesagt: // Derek Holzer wrote:
> Test patch attached... see the [wraparound~] subpatch for the part which
> doesn't work yet!
I added a [tabread4~ test_zample] and now it works. ;)
Now seriously: The forgotten tabread probably wasn't the error you
were looking for. But
Hi Roman,
and thanks. I implemented it in my patch, but it doesn't seem to work
right. The looping isn't seamless, in fact there's a "hiccup" at the
point where the loop wraps around. In my previous version, I had another
function to calculate the offset and start point, so what would work
be
hi derek
i attached a patch, that should do what you want. it is a modified
version of IOhannes approach, but it is still only a [wrap~] with
scaling functionality.
roman
On Mon, 2007-05-07 at 19:00 +0200, Derek Holzer wrote:
> I tried this already, and it's not appropriate in this case. The id
Sorry, last patch was missing the tabread!
Use this one!
d.
Derek Holzer wrote:
Test patch attached... see the [wraparound~] subpatch for the part which
doesn't work yet!
d.
Derek Holzer wrote:
I tried this already, and it's not appropriate in this case. The idea
is to change the start
Test patch attached... see the [wraparound~] subpatch for the part which
doesn't work yet!
d.
Derek Holzer wrote:
I tried this already, and it's not appropriate in this case. The idea is
to change the start of the loop to any place in the sample. If the
length of the loop is longer than what'
I tried this already, and it's not appropriate in this case. The idea is
to change the start of the loop to any place in the sample. If the
length of the loop is longer than what's left of the sample in the
table, currently I get silence. If I use [wrap~] the way you describe
it, the loop I sel
Derek Holzer wrote:
>
> end of the table)? [wrap~] doesn't do the trick, BTW.
i am sure it does.
try scaling the signal before sending it to [wrap~] and afterwards undo
the scaling.
[/~ 100]
|
[wrap~]
|
[*~ 100]
mfa.sdr
IOhannes
___
PD-list@iem.at ma
I'm grinding my teeth trying to work out an audio signal version of
[mod]. I have a [phasor~]-driven looping abstraction with a variable
loop point, but sometimes the parameters I send it cause it to go past
the end of the table, resulting in silence when I'd rather it started
playing immediate
20 matches
Mail list logo
