I had this exact same problem when sending large amounts of OSC data from oF to PD. I ended up creating another oF program that receives the OSC data, converts it to PD's FUDI message format, and then sends the converted message along to PD. This helped reduce the delay a bit. I also modified my oF program to only send the continuously updating OSC data every X frames. This isn't an ideal solution but it worked well enough for my project.

Another possible solution would be to use the ofxPd addon and redo everything using libPd.

You can theoretically use the {soundfiler} object with the -raw flag to import anything into an array.

The number box on the right sets the value. The bang outputs the value. If you send a number to the left [trigger] object it will add it to the value and output it.

If you want to be able to check the audio at will you can use the method you described and store the result in a named [value] or [v] object. Then you can check the current state anywhere in your patch by banging a [value] with the proper name.

If you only need to check the audio at a single point in the patch then you can use the cold (right) inlet of a [float] or [f] object to store the state and bang the hot (left) inlet to retrieve it.

It kind of depends on what you want your sampler to do. If I am playing back one-shot sounds I prefer to use [line~] but if I am dealing with loops a would rather use [phasor~]. I find that it is more intuitive to do all sorts of wacky beat slicing and transformations using [phasor~] but I don't really think there is a significant difference in CPU usage.

If you want to keep it vanilla (though not lgpl) you can do something like:

[phasor~]   [.2(   [.9(
|           |      |
[expr~ if($v1 > $f2, if($v1 < $f3, 1, 0), 0]
|
[lop~ 64] <-change this to change the attack and release on the window

The [expr~] object should output an audiorate 1 if the input is between .2 and .9 and an audiorate 0 otherwise. The nested ifs are used to simulate something like :

if ($v1 > $f2 && $v1 < $f3) {
  return 1;
}
else {
  return 0;
}

The [lop~ 64] object is for smoothing out the sudden jumps between 0 and 1.

Another approach is to drive a windowing function or table lookup using the same [phasor~] used to drive sample playback.
One approach would be to do something like this:

[phasor~]
|
[*~ .5]
|
[+~ .75]
|
[cos~]
|
[*~ 100] <-change this to change the attack and release of the window
|
[clip~ 0 1]

Here we are taking the [phasor~] signal and using it to drive the positive half of a cosine function. We then scale this function up to increase the slope of its attack and decay. Finally we use [clip~ 0 1] to give it a maximum value of 1 instead of 100. Essentially this gives us a square like function with sinusoidal attacks and decays at the ends.

Make sure that you have a large enough buffer size in ASIO4ALL and PD.

I would try modulating the frequency by another [osc~] object. This should give it a more characteristic sound.

[osc~ 2] <-set 2 to the rate of the sweep in Hz
|
[+~ 1]
|
[*~ .5] <- the +1 and * .5 are to put the modulating osc into the range of 0 to 1
|
[*~ 3000] <- range of frequencies
|
[+~ 1000] <- lowest frequency
|
[osc~]
|\
[dac~}

@gsagostinho

You added an extra comma in your diagram. Also you probably want to use [line~] instead of [line] when dealing with audio-rate ramps.

1. Yes. In theory you would need to resize your array and copy some samples around. In practice it doesn't matter very much for most sampled sounds. You will get some minor interpolation errors on the wraparound but there is little chance that they will be noticeable. Whenever I design samplers in PD I don't make any array changes. If you are using [tabread4~] to scan through an array to generate a control signal then you might want to consider changing your array.

2. I believe you are correct with 1 to 44101. The guard-points are for when you try to read something like sample 0.25 or 44101.5. You can get more info on the interpolation method here: http://msp.ucsd.edu/techniques/latest/book-html/node31.html

If you have any experience with Java or Processing you can try to make your own keyboard/mouse controller using the Java Robots class. This should work on any platform. If you use this with Processing you can easily drop in some OSC functionality and link it up with PD. I was able to use this technique along with the [fiddle~] object to play Quake with a saxophone and electric bass as the controller.

Info:
http://www.java-tips.org/java-se-tips/java.awt/how-to-use-robot-class-in-java.html
http://docs.oracle.com/javase/7/docs/api/java/awt/Robot.html

Another thing to note is that [rotateXYZ] allows you to specify rotation around the x, y, and z axes while [rotate <x> <y> <z>] rotates around an arbitrary axis defined by a vector (x,y,z).

You might want to try it without the [list split] object. Many of the vanilla PD objects will take a list of arguments given to the first inlet and distribute them across the remaining inlets. For example:

[3 2(
|
[- ]
|
[> -1]  <-number box

Another thing to try is using the [unpack] object instead of the [list split] object.

A possible solution would be to give each instance of the abstraction a unique identifier as an argument and have them save and load the data to disk using a filename based on this identifier. This solution does use arguments but it only uses one.

[table myTable 32]

[loadbang] <- auto load table data
|
[i $1] <-$1 is the unique id
|
[read tabData-$1.txt(
|
[s $0.myTable] 

[bang( <- save table data
|
[i $1]
|
[write tabData-$1.txt(
|
[s $0.myTable]

With an id of 4 this will load the contents of tabData-4.txt into the abstraction's own $0.myTab array. The [bang( will write the contents of the array back out to tabData-4.txt.

You don't need an external to write a list to a table. You can do something like :

[0 2 -1 -1 1 1 1 -1(
|
[s rhythm]

[0 0 1 1 0 0 0 -2(
|
[s melody]

The 0 at the beginning indicates which index to start from.

Alternatively you can do the whole thing in a single message:
[;rhythm 0 2 -1 -1 1 1 1 -1; melody 0 0 1 1 0 0 0 -2;(

I downloaded the Windows build of PD 46 from Miller Puckette's site and all the help files worked fine.

That's strange that it can't find the help files. I've attached them here.
oscparse-help.pd
oscformat-help.pd
netsend-help.pd
netreceive-help.pd

How are you sending the OSC data? It sounds like you are sending normal FUDI messages to the [oscparse] object instead of binary OSC data. If you are sending the data using pd then make you need to make sure that you also use the [oscformat] object and that you also use the -b flag on the [netsend] object. The -b flag is also needed on the [netreceive] object to let pd know that it is receiving a binary data stream and not FUDI messages. Pd 0.46-0 should have help files for all of these objects that give examples of their use.

If you update to PD 0.46-0 you can use the [oscparse] object which does exactly what you need.