Ok, this might be a very basic question, but I wasn't able to find a satisfactory answer through searches, so here I am. Is there any difference between the [mod] object and the [%] object? In Designing Sound by Andy Farnell and on Karim Barkati's Reference card, the [] object is listed as a 'bit twiddling' object, but functionally, I can't find any difference between them and I've been using [%] to get remainders all along and just found out about [mod].

Hi all, I'm working on a patch that pulls a random wav file from a directory, plays it and then when it's getting close to the end, opens another random file and fades from one to the other. It's a pretty basic idea, but I'm pretty new to pd, so almost every step of that process has been challenging.

I've managed to get most of it put together by watching different tutorials and using example patches people have posted, but there seems to be a big limitation that I haven't found a good solution for yet. I am hoping to use wav files ranging from about 5~10 minutes long.

I'm currently reading them into arrays and playing them with tabread4~, which basically works except that it freezes up when loading either file, meaning it will be seemingly impossible to use this method to get an uninterrupted stream of sound. It also doesn't seem to handle 10 minute long files very well - they seem to be cut off from what I can tell in the array.

Alternatively, it seems like I could use readsf~, but then I'm not sure how I could know when to load/start the coming file, since it doesn't seem to offer the control that tabread4~ and arrays have.

Oh, I'm using Linux by the way. Thanks for any help you're able to offer!

Here are all the instances I found:

print: 6.17274 play granular object 2 0 1 0 1.02879 0 0 100
print: 6.06735 play granular object 3 0 1 0 1.21347 0 0 100

print: 10.9295 play granular object 1 0 1 0 1.09295 0 0 100
print: 10.9212 play granular object 3 0 1 0 1.21347 0 0 100

print: 17.4894 play granular object 2 0 1 0 1.02879 0 0 100
print: 17.4872 play granular object 1 0 1 0 1.09295 0 0 100

print: 21.859 play granular object 1 0 1 0 1.09295 0 0 100
print: 21.8425 play granular object 3 0 1 0 1.21347 0 0 100

print: 26.7485 play granular object 2 0 1 0 1.02879 0 0 100
print: 26.6963 play granular object 3 0 1 0 1.21347 0 0 100

print: 32.7885 play granular object 1 0 1 0 1.09295 0 0 100
print: 32.9213 play granular object 2 0 1 0 1.02879 0 0 100
print: 32.7637 play granular object 3 0 1 0 1.21347 0 0 100

print: 34.9789 play granular object 2 0 1 0 1.02879 0 0 100
print: 34.9744 play granular object 1 0 1 0 1.09295 0 0 100

print: 40.1228 play granular object 2 0 1 0 1.02879 0 0 100
print: 40.0445 play granular object 3 0 1 0 1.21347 0 0 100

print: 46.2956 play granular object 2 0 1 0 1.02879 0 0 100
print: 46.1119 play granular object 3 0 1 0 1.21347 0 0 100

print: 52.4683 play granular object 2 0 1 0 1.02879 0 0 100
print: 52.4616 play granular object 1 0 1 0 1.09295 0 0 100

print: 53.4971 play granular object 2 0 1 0 1.02879 0 0 100
print: 53.3927 play granular object 3 0 1 0 1.21347 0 0 100

print: 54.6475 play granular object 1 0 1 0 1.09295 0 0 100
print: 54.6062 play granular object 3 0 1 0 1.21347 0 0 100

print: 60.6986 play granular object 2 0 1 0 1.02879 0 0 100
print: 60.6735 play granular object 3 0 1 0 1.21347 0 0 100

print: 65.577 play granular object 1 0 1 0 1.09295 0 0 100
print: 65.5274 play granular object 3 0 1 0 1.21347 0 0 100

print: 66.8714 play granular object 2 0 1 0 1.02879 0 0 100
print: 66.7409 play granular object 3 0 1 0 1.21347 0 0 100

print: 69.9577 play granular object 2 0 1 0 1.02879 0 0 100
print: 69.9488 play granular object 1 0 1 0 1.09295 0 0 100

print: 74.0729 play granular object 2 0 1 0 1.02879 0 0 100
print: 74.0217 play granular object 3 0 1 0 1.21347 0 0 100

print: 76.5065 play granular object 1 0 1 0 1.09295 0 0 100
print: 76.4486 play granular object 3 0 1 0 1.21347 0 0 100

print: 80.2456 play granular object 2 0 1 0 1.02879 0 0 100
print: 80.089 play granular object 3 0 1 0 1.21347 0 0 100

print: 87.4472 play granular object 2 0 1 0 1.02879 0 0 100
print: 87.436 play granular object 1 0 1 0 1.09295 0 0 100

print: 93.6199 play granular object 2 0 1 0 1.02879 0 0 100
print: 93.4372 play granular object 3 0 1 0 1.21347 0 0 100

What I found weird at first is that it didn't seem to correlate with differences below a certain threshold. For example, 93.6199 - 93.4372 = 0.1827, but you can find examples with a smaller difference in time that are aligned correctly. For example, 31.5502 and 31.6956 only have a difference of 0.1454, but they show up like you expect them to. So what gives?

In pd, the order in which you connect things determines the order they happen in. While you have a single bang at the top to start it off, that doesn't mean that these things are really happening at the same time. If you go through all the errors I've listed above, you'll notice a few patterns. First, 2 is never "late" (though as we'll see in a second, I don't think that's really what's happening). So we can assume if they're offset, 2 is ahead of the other two. That means, I would guess you connected the top bang to object 2 before the others. Next, you'll see that 1 & 3 are always late, but that 1 is never late after 3. So I'll guess that you connected 1 after 2, but before 3. How is this relevant?

I believe what's happening is that there is a computational delay between the three bangs that offsets your three separate timers from the get go. Since you have three rather than two, it makes it harder to figure out why that's happening. But essentially I think if you can find a way to use a single timer, then you will be able to get the results you're looking for. I'm not sure what your goals are though, so I don't know if that's really feasible. Otherwise, you could try to sort them before you print, but I'm guessing that's an even less helpful solution. Other than those two choices, I'm out of suggestions. But at least, you know where your problem lies now.

Yeah, actually I have already redone it with readsf~ and overall it's way simpler and more elegant so far than it was with soundfiler~, arrays and tabread4~. As of now, I am fine loading new files and playing them without dropouts. I have also figured out how to get the length using [soundfile_info] (which also give me the samplerate as well.

I still haven't quite gotten it working yet though. I am getting weird issues not being able to use [timer] or [realtime] to compare with the time I want. I wanted to port part of functionality into a separate patch, but I think I may be creating unnecessary problems for myself that way and may have to just do the whole thing in one patch after all. Anyways, the original issue seems to work well combining [readsf~] and [soundfile_info], so thanks for the suggestions!

Hi Johnny, I did see that topic when I was looking for a solution. I also watched katjav's youtube video (and her other videos, which are all awesome!). Thanks for linking her explanation, which I didn't see before. While I was impressed with her efforts, I didn't really understand how it related to soundfiler~ until reading that page.

It actually brings up an interesting point further down though. Maybe my problem isn't necessarily the use of floats, but the inability to load sound files in the background without the sound dropping out. I thought the dropout was related to the long files, but maybe that isn't the case. Will pd-double even solve that issue?

mnb, I think that second suggestion might allow me to simply use readsf~ if I can find out how to do that. I will look into it.