# K4 Sample Start Offset in DFD Mode



## kotori (Feb 17, 2011)

Big Bob @ Thu Feb 17 said:


> It seems like the way this should have been done in DFD mode is to add ofst to S.Start (as long as ofst is equal or less than smod) and not just reference ofst to the beginning of the physical sample.



Hi Bob,
I completely agree. I wonder if get_event_par(EVENT_ID, EVENT_PAR_PLAY_POS) could be used to compensate for it. Here is a longer example of the concept.

Cheers,
Nils


----------



## Big Bob (Feb 17, 2011)

Hi Nils,

I can't find any documentation on EVENT_PAR_PLAY_POS in my KSP manual, however, I tried using it anyway. But it always seems to return a zero value no matter where I position the S.Start flag or what value I use for the play_note ofst. I was hoping that this might provide a means for a script to find out what the current zone's S.Start position is. Without some means of reading the S.Start position, I don't see how this problem can be 'worked around'.

Did you by any chance give me the wrong 'longer example' link? The example seems to illustrate a round-robing scheme and I don't see any usage of EVENT_PAR_PLAY_POS in it (but maybe I missed it).

Do I presume correctly, since you didn't say anything about the K4.2 beta, that this implementation problem is still not rectified? Has anyone suggested to NI that this be changed? I wonder why the play_note ofst isn't treated like any other modulation source??? :? 

Confused as always :lol: 

Bob


----------



## EvilDragon (Feb 17, 2011)

That's Kontakt v4.2 material that Nils mentioned.


----------



## kotori (Feb 17, 2011)

Bob,
for the EVENT_PAR_PLAY_POS to work the sample needs to have started playing (that the event id is in the note queue is not enough). That's what the linked script shows - how to start a short inaudible blip first just in order to extract the informationen. 
I don't remember if EVENT_PAR_PLAY_POS is relative to the sample start offset or the start of the sample though. It's a K4.2 feature.


----------



## Big Bob (Feb 17, 2011)

> for the EVENT_PAR_PLAY_POS to work the sample needs to have started playing (that the event id is in the note queue is not enough). That's what the linked script shows - how to start a short inaudible blip first just in order to extract the information



Ah So! Thanks for the clarification Nils

But since it doesn't work at all in K4.1.3 I guess I will have to wait for K4.2 then? 

However, no one has answered my question about whether the DFD offset mechanism works differently in K4.2 than it does in K4.1.3? I'm hoping some one is going to say that in K4.2 the play_note ofst is made relative to S.Start in DFD mode (as it is in Sampler mode) as opposed to being relative to the physical sample start (as it is with K4.1.3). Has anyone with K4.2 checked for this?

Bob


----------



## Big Bob (Feb 17, 2011)

Hi Mario,

Just for kicks I did the blip note thing and retried reading EVENT_PAR_PLAY_POS and now *I can read it*. So, apparently this parameter *is* readable in K4.1.3 also.

However, I must be going nuts because now nothing seems to work the way it did yesterday :o . I guess I had better crawl into a quiet corner and start all over before I go off half cocked again :oops: 

To be continued when my head is back on properly :lol: 

Bob


----------



## Big Bob (Feb 17, 2011)

It turns out that my initial posting was the result of incomplete testing. I'll now try to summarize (correctly I hope) how the DFD offset thing really works. But, the good news is that it can be made to work exactly like it does in Sampler mode providing that certain boundary conditions are satisfied.

To simplify this discussion, I'll define some symbology and terminology. All time positions will be expressed in microseconds. I'll refer to the physical beginning (time = 0) of the sample as *S0*. The *S.Start *flag position (in microseconds) will be called *SS* while the *S.Mod *setting in microseconds will be refered to as *smod*. Finally, the offset time (in microseconds) in the play_note(n,v,ofst,p) function will be refered to as *ofst*.

Note that in the wave editor, the *S.Start *and *S.Mod *values are shown as samples so these settings will need to be divided by the sampling rate (in samples per second) and then multiplied by 1000000 to be expressed in microseconds.

In Sampler mode, the play_note function always starts the sample playing from *SS + ofst*. It turns out that the sample will also start playing from *SS + ofst *in DFD mode providing that *smod >= (SS + ofst)* or if *ofst <= 0*

If *smod < (SS + ofst)* and *ofst > 0* the sample will play back starting at *smod* but only if *smod >= SS/2*. If *smod < SS/2* and *ofst > 0*, the sample will not play back at all. I believe this is the set of conditions that are responsible for SIPS not working properly under K4. Prior to K4, a non-zero ofst value in the play_note functions was simply ignored in DFD mode. I haven't reviewed the SIPS coding yet but I suspect there are situations in which ofst is non-zero in DFD mode (because it was previously a don't-care situation).

If the above assertions are correct, for a script to be able to offset the sample start position by any amount from zero to *OfstMax*, it will be necessary to set the *smod* value for each zone involved to a minimum of *SS + OfstMax*.

It would seem to me that requiring *smod >= OfstMax *or at most *smod >= 2*OfstMax * (to be consistent with other bipolar modulators) would be sufficient. But apparently, the way NI implemented this thing involves 'reaching' from the actual physical sample start, *S0* rather than relatively from the *SS* point.

When the 'reach' distance (*SS + ofst*) exceeds *smod*, the value is clamped to *smod*. This in itself wouldn't be so bad but when* smod *isn't big enough to reach inside the modultion zone (*SS +/- smod*), the sample won't play at all. This is perhaps the most confusing artifact of this implementation.

Since a bi-polar modulation zone is implemented for all other modulators, one would think that NI would also allow negative *ofst* values for the play_note function but apparently any value less than zero is just clamped to zero.

Maranatha,

Bob


----------

