i have been beating my head against a wall for 2 days.

I made the switch to ubuntu studio 12.04 recently, from windows 7. i have been running my patches on win 7 with no significant issues other than typical windows cpu bloat. i have had a running looper abstraction running for months. now, for some reason, trying to run the same abstraction in 0.43.1 pd-extended for ubuntu 64bit, the aspects of the patch responsible for looping, are all out of whack.

once i hit the record then the overdub, the resultant loop is immediately half the length and pitch of what i played, although the loop length is exactly what it should be, so each go around the recording pitch and length blip into nothing but a slight "chip" sound at the loop start.

i have taken some of the main bits of code and made this patch. it works fine in windows but not in linux. are there any other aspects of swtiching to linux that i should be aware of, that will affect my patching?

(actually, the example patch is more screwed than the patch i need help with and for similarly mysterious reasons so i will include it anyway)

thank you in advance

Onyx

http://www.pdpatchrepo.info/hurleur/looplayer.pd

Hey Onyxashanti,

Good thing you switched to Linux! 64 bit Linux is not the easiest to handle Pd however. Some Pd devs may even still be on Linux 32, so they can not test everything to work well. You may better try Linux 32 bit if Pd is one of your vital softs. I have Debian Squeeze installed, and the looper you're using is in my main setup, it works well.

One remark about your post: if you upload a crippled patch like that, would you please remove my name from it?

Katja

oops, sorry! i didnt think about that. i have changed it now.

yeah, its bugging me. me and servando have been trying to figure out whats happening and we arent getting anywhere so maybe that is the issue, because it doesnt happen in windows. i will report back. thanks for the advice. servando says "hi!"

onyx

i tried to install the 32 bit version and the dependencies are just too old. i moved back to the 64bit 0.42.5 version.

everything else works super. its just that when i record the loop, upon stopping the first recording pass that sets the loop length, the first loop recording is half the length of the loop, so it plays really fast til the end of the loop time which triggers a bang at the vline~ on each go around. the next go around is half the speed and pitch of the previous one and so on until its is just a tiny blip sound at the beginning of the loop time where the bang occurs.

i made an array to visualize to table data but nothing shows up in the table at all. should poke be getting the sample rate index or the millisecond length, to its middle inlet? and wouldnt the recording show up in a named table?

i am sure it is something i have done to keep this patch from operating properly. i am willing to investgate any/all possibilities.

cheers

onyx

That's weird Onyx, sounds like poke~ operates at half the samplerate. But why? [tabread~] and [poke~] get the same index from [vline~], no? Check it with [snapshot~] objects. As a test, you can fill a table with index numbers using poke, feeding the index numbers into [poke~]'s first and second inlet.

By the way, you say 32 bit did not work, but did you install a complete 32 bit Linux system, or only a 32 bit Pd on 64 bit Linux (that will not work)?

By coincidence, I'm working (together with other people) on a Pd port of MaxMsp class [ipoke~] by Pierre Alexandre Tremblay. It can write with interpolation at any speed. Meaning you can change the tempo of a sound on sound looper at any moment. This is so cool. Hopefully we'll soon be able to release an alpha version. Thread starts here:

http://lists.puredata.info/pipermail/pd-list/2012-06/096556.html

Katja

oooh, i can not wait for that. please keep me informed.

we were tallking about your amazing performance in france today actually. very inspirational.

i just checked with bangs on the loop point into snapshot objects and it seems that it bangs the full loop value, like 43678 but then it jumps back to 15 then to 43678 then to 15, and on and on on each bang. when i tried to subtract 15 from it, the lowest value became 30 (!?!) so i added 15 then it became 0 but the problem persisted.

i made a patch to show this error. tell me if it shows up on your system. i may be banging something that is adding a value where it shouldnt be, but why would it not happen on windows or a 32bit system #weird.

thanks!!!

Onyx

http://www.pdpatchrepo.info/hurleur/looplayer_example.pd

Onyx, I ran the patch on OSX because I don't have my Linux box with me now, and I get index 1 from [count~] and index 2 from [pd readindex]. In fact it should be 0 and 1 respectively, the first numbers in the signal block. But this seems to be due to [snapshot~]. This lead me to the idea of checking with [print~] instead, which gives me the expected values. [print~] gives all values in one signal block, so you can use this to check if more numbers are skipped. In my case no value is skipped. Can you post such results from [count~] and [pd readindex~]?

And please say hello from me to Servando, will you? I'm recommending his Minia controllers to everyone.

Katja

i am getting the same results you mentioned:

(ri is the read index output)

print~:
0 1 2 3 4 5 6 7
8 9 10 11 12 13 14 15
16 17 18 19 20 21 22 23
24 25 26 27 28 29 30 31
32 33 34 35 36 37 38 39
40 41 42 43 44 45 46 47
48 49 50 51 52 53 54 55
56 57 58 59 60 61 62 63
ri:
1 2 3 4 5 6 7 8
9 10 11 12 13 14 15 16
17 18 19 20 21 22 23 24
25 26 27 28 29 30 31 32
33 34 35 36 37 38 39 40
41 42 43 44 45 46 47 48
49 50 51 52 53 54 55 56
57 58 59 60 61 62 63 64

so maybe the poke implementation is screwy. is there an object or abstraction that it can be replaced with?

I will definitely let him know!! thanks for your insight!

Onyx

Indeed you now know that the index numbers sent are correct, so the problem may be with [tabread~] or [poke~]. By the way I use [tabread4~] in the looper now. Even though I don't know why it should work better theoretically, it does so in practice.

[poke~] is no longer maintained by the original author, and the code was never really worked out completely. But if you can create a simple test patch which proves that [poke~] is definitely at fault, you can file a bug report and someone may be able to fix it. Like I said, fill a table with index numbers using [poke~]. Then you look at the table content with message [arrayviewlistnew <tablename>( and if some numbers are skipped there's something wrong with [poke~]. I know of no way to replace [poke~] at the moment but someone else may have a suggestion. Or else you could do the looper with [delwrite~] and [delread~], but you'd need to convert to milliseconds instead of samples, and the buffer can not be cleared with a single click.

Katja

you are right. i just checked it out on my 32bit netbook pd install and the patch runs properly. poke~ in the 64bit install is faulty. isnt there a cyclone library made of vanilla objects? i also tried to copy the poke from the 32bit to the 64bit version and that obviously didnt work well but it was worth a shot.

I will see if there is any other poke-replace solution as well. any ideas? thanks for the insight. i was thinking it was my patch so at least i know now that it is this one object!

onyx

ok, so i spent the afternoon searching for poke~ replacements and i cant find anything. i really dig the capabilities of how katjav implemented the poke~ based circular buffer and would like to keep it.

is there any way that anyone knows of to find or create an alternative to poke~? katjav, you mentioned something you were working on called ipoke. i would be a willing beta tester!

my other thought is to have stacks of synchronized tables, for which i already have an abstraction i created, but i would like to have the elegance of the poke~ solution for feedback control and the ability to clear the buffers.

or...

is there a way i havent investigated, to bring a working poke~ object from another build? would this work and if so, how would i go about it?

thanks in advance!

Onyx