I have an OSC device that you could think of like a slider--when you touch it along a line, it produces a float between 0 and 1, corresponding to the proportional distance along that line.

It's easy to feed its output into osc~ and make a sine wave audio--sounds like a slide whistle. How do I use it to index a play position in an audio file, thus enabling scratching?

I have a patch I am distributing with some other software. The patch uses some .ogg files. I want to package it all in a directory together, so users can copy from an archive (.dmg on the mac) to a directory, and run the patch easily.

So my patch needs to be able to find my ogg files. [open ./file.ogg( doesn't work--the . is relative to the local directory where pd is invoked if you do it from the command line, not the directory where the patch is. I don't want to ask users to use the command line.

[~/dir/file.ogg( doesn't seem to work either: oggread doesn't seem to be able to translate ~ into /Users/username.

I'm using v 0.40. I 'm running Mac OSX 10.5.5.

So how would I do this? I need to make it simple for end users.

I'm trying to create a subpatch where I pass in a filename as a parameter. I want to send in a 'loadbang' signal, and then a message 'open $1' to an oggread~ object. I've tried 'symbol,' I've tried a few things. 'makefilename' doesn't seem to do what I want. Any ideas?

I have a widget that basically works as a slider. It generates streams of OSC data, which I'm receiving with a PD patch. You could think of it as a slider combined with a switch, so you can control an alpha-value (ranging from 0-1) by sliding along the surface, but it also (to a separate OSC address) sends a 1 when you put your finger on, and a 0 when you take it off. That way you can make the slider output only active when you touch it, or not, as you see fit.

Problem: how do I combine these inputs into a continuous signal? When I just feed them into a && or a * they seem to want a bang input, too.

I want to package some .ogg files with a patch that will be bundled in a tarball with some other stuff. So referring to them in the patch by way of 'open /Users/jstoner/file.ogg' isn't gonna work.

So I need to use relative paths. So I

cd /Users/jstoner/.../pd
/Applications/Pd-extended.app/Contents/MacOS/Pd-extended --open oscserv.pd

(this is on my Mac, OSX 10.5.4) thinking this would be good function to do in a bash script. It starts, but it doesn't open my patch. When I open the patch manually, it does find my oggs by relative path, so I got that going for me. But I'd like to make this easy for users.

So is -open just broken? or is there something else I'm missing?

OK, I've got it... I had two problems:

there's an interval of time--a bite of the sample (50 milliseconds in the attached patch). It needs to be the same length as the time fed to vline~. Duh.

Also, modulo can return a negative number. -17 % 5 = -2. That doesn't work for computing the index into the sample.

This scratches nicely. It's set up with the length of the slider set to the same interval of time as one turn on a 33 1/3 record. Playing with th bite size is interesting--too low and scratching is just annoying. Didn't really play with values over a fifth of a second.

I'm sure there are more efficient ways to implement this. I'd be curious to hear about them from pd gurus.

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

Ok, turning my attention back to this...

Still not getting a good sound out of this patch. when I switch to scratch, and I move the slider right I get a buzzing sound, and when I slide left I get silence, with intermittent popping. I recently saw this:

which looks similar to what I'm trying to do here.

Any ideas? I've attached a version of this patch that you can interact with without an OSC input. Just pick a sample and slide the slider.

Ok.... got this far.

The attached patch loads and plays a loop. It has a toggle that starts/stops the loop. it has an OSC-based switch between playing and scratching.

The playing works fine. The scratching doesn't sound good--close but too fragmented, like it's playing bits and pieces of the sample, not in a smooth way. If anyone knows a way to make this sound better, I'd appreciate your wisdom.

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

OK figured that out, I think. Next up, stopping the phasor~ and incrementing from the change value output. Any ideas would be much appreciated.

OK... found [pipe]. Which doesn't exactly do what I think I need. Pipe makes a delayed stream of numbers. My first thought was, stream the output of pipe and the raw numbers to [-] and get the differences. The trouble is, I'm measuring overlapping intervals, which will move the scratch farther than I think I want.

I think I want to measure the 'slider's' motion incrementally. Like at intervals, measure how far it's moved in that interval and return that value. I think there's a metro and a pipe in that patch, but I can't quite figure out how to pull a value out of a stream at intervals. Any ideas?

OK... got as far as a phasor~ I can switch on and off, playing a sample. Borrowed from a youtube video. It works, well. Now I need a way to base the change in the indexing into the array on the change in the slider. So I need to track the difference between the current frame of data and the previous frame. I don't see a way to do that.

That is so cool and simple. Thanks! Sorry, should have said something sooner.

Here's a more complicated case--what if I want to loop the sample, and scratch from where I'm at at that moment instead of using my slider to determine the position in the sample directly?

I understand if you don't wanna create the code, but if you could point me in a direction, that would be helpful.

Yeah, that's the one. I'm looking at readsf~ now. Uncompressed isn't a big deal for me--inflates file sizes, but not egregiously. Thanks for the help.

well, attached is a pretty basic way to produce the problem... do you know a more reliable way to play an audio sample? Anyone? I'm new to this whole field, but this seems like pretty basic function to me.

This patch works if I start pd from the command line, but if I just click the app icon on the mac, I get this on the log:

oggread~: ogg/vorbis file reader version 0.2c, written by Olaf Matthes
oggread~: file "oh.ogg" opened
oggread~: error: could not open "oh.ogg" as an OggVorbis file
oggread~: file closed due to error
oggread~: file "oh.ogg" was not seekableoggread~: first logical bitstream information:

then when I try to play it bombs.

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

It does have to do with the sampleplay abstraction. When I add one of the sampleplays back in, connect it up, turn on 'compute audio,' send in an OSC signal, and wait a few seconds, it crashes.

When I copy the code out of sampleplay and replace the abstraction with direct invocation of the objects, it crasheswhen I send the OSC signal. When I erase the code and rewrite it, it crashes when I send the OSC signal. Just the one audio file is enough. It used to work fine with this audio. It still works fine if I invoke Pd from the command line.

http://www.pdpatchrepo.info/hurleur/oh.ogg

sorry, tried to send both in quick succession, and it said 'wait 60 seconds, and I got distracted...

and this...

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

duh, right... I don't think it's that big.

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

OK, that sounds reasonable, but now if I launch from the finder or quicksilver, it dies. From the command line it seems to work ok. Is that normal? I'm running Pd-extended 0.40.3, on an Intel Mac.

log messages:

written by Hans-Christoph Steiner <hans@at.or.at>
compiled on Jun 27 2008 at 03:24:21
compiled against Pd version 0.40.3.extended-20080627

aaack--that's not right either.... never mind. Had to save the abstraction to pick up my changes. It works now.