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