how to add offset

[tester]

I received info that you already have access to new FS releases.

I don't know if this crashing problem is related only to asio. I use directsound, but - also exe apps. Although I'm starting to have some doubts about clearaudio prim, since I did not removed all the selectors.

Yes, the waveplayer is important to expand and make work with longer files. Otherwise, any audio explorer (like the one from Exo, with custom start/end points) - will lbe simpy useless.

In the waveplayer (Exo - this is for you?), there would be two interesting things to do:

1) Developing "find zero crossing" (+/- or -/+) routine, so that start/end points can snap to null points (ti probably does not have to analyze the whole files, just +/- n samples per mouse release on start/end handler).

2) And/or - custom crossfade between start/end section (time length + crossfade type), so that loaded file is looped smoothly by default. Crossfade solution probably will elliminate the need for zero-crossing finder.

[tester]

@tester check out my free running polyphonic oscillators for an example of using the "Mem to address "

@KG_is_back the "Mem to address " is actually a very old primitive called "to int" which was hidden. If you download my free running oscs (you should be able to force load it) you will get access to it, just wrap it in a module and pop it in your toolbox.

I reinstalled 304 and realized what do you mean by "to int" (when I moved between computers, on which different versions are, I just overlooked it). Are there any other else hidden prims out there worth to know?

But what a relief. I could export my project with an older FS release, and it works and without crashing.

[KG_is_back]

1) Developing "find zero crossing" (+/- or -/+) routine, so that start/end points can snap to null points (ti probably does not have to analyze the whole files, just +/- n samples per mouse release on start/end handler).

Something like this? (sorry for the unfinished GUI)

[tester]

I'm outside FS for a moment, but from what I remember - yes, something in this direction. One zero crossing finder would snap to the start handler, the other one - to the end handler. Exo did pretty usable interface for start/end point selection, although it may require some cleaning from what I saw.

A few thoughts.

1) Finding zero crossing in stereo waves may be a little bit more difficult, because channels don't match.

And BTW, is the wave loader loading mono files to memory "as is", or is it converting them into dual mono? (2 channels with the same content). I haven't checked that.

2) Rather simple to do - "find opposite zero crossing for second handler" if other one is at zero (this would include start and ent poiints of file as well, where only one side is preset), and "find any" if the other one is not at 0.

*

All this leads me to the conclusion, that short crossfade on looped playback might be better, but I don't know if it's easily doable. I guess (I could be wrong; non-programmer way of thinking!) it would be based on some sort of buffering (start/end selection mix) and switching between core mem and mixed crossfade part. Such crossfade could allow to set the lenght (personally I would use few seconds lenghts, but for some sounds it's a matter of few miliseconds), and curve (to reduce gain damping).

[KG_is_back]

1) Finding zero crossing in stereo waves may be a little bit more difficult, because channels don't match

Yes, that is true. Most often in such situations only one channel is used. Another approach is to use the sum of the channels or first find zero crossing on one channel and use that as a starting point to find zero crossing on second channel, then average the two values.

And BTW, is the wave loader loading mono files to memory "as is", or is it converting them into dual mono? (2 channels with the same content). I haven't checked that.

normal wave loader loads mono waves in true mono = the mem is a sequence of values. The stereo wave is a sequence of pairs of values. When you load a wave file the wave read prims are recompiled to read stereo or mono mems (there are two versions of code). That is why the custom wave read needs to know which one to use and use appropriate code.

Wave array is different - all waves are converted to common format (either mono or stereo).

All this leads me to the conclusion, that short crossfade on looped playback might be better, but I don't know if it's easily doable. I guess (I could be wrong; non-programmer way of thinking!) it would be based on some sort of buffering (start/end selection mix) and switching between core mem and mixed crossfade part. Such crossfade could allow to set the lenght (personally I would use few seconds lenghts, but for some sounds it's a matter of few miliseconds), and curve (to reduce gain damping).

I've experimented with that already. Basically you need two wave read prims, that read the wave in parallel. When one reaches the start of crossfade, the second starts to read the wave from the start-loop-point. After them, both signals are crossfaded with a gain curve. Custom wave read might come handy in such situation, because in assembly you can make the second wave read active only during crossing to save CPU.

[tester]

Filesize is in bytes and you need to limit the index to index of last value (we are speaking of indexing the values in ram where you refer to bytes - not typical indexing where 0 is first sample 1 is second etc.). in case of Stereo wave file, that is filsesize-8 (because value consists of two 4byte floats). it is because indexing starts from zero.

In other words, if mono wave is loaded, then this value must be -4 (switch), yes?

Typical problem might be occasional crashes, when changing the wave file during high CPU load. The address passes partially through green and may arrive late to the custom wave read, while the previous address is already invalid.
Another thing to test is loading the schematic with engaged sound card and with no wave loaded. I've observed that when no mem is connected the address and bytesize is still nonzero and apparently random, so there is no way to tell.

Mem pointer vs mem size, yes? Isn't it solved by the order of triggers, like in Exo's schematic? (attached below; I guess the amount of channels should be checked in the same way - first mem pointer, then channels).

Anyway this part can be probably solved by either trigger order or sending values on confirmation triggers.

All this leads me to the conclusion, that short crossfade on looped playback might be better, but I don't know if it's easily doable....

I've experimented with that already. Basically you need two wave read prims, that read the wave in parallel. When one reaches the start of crossfade, the second starts to read the wave from the start-loop-point. After them, both signals are crossfaded with a gain curve. Custom wave read might come handy in such situation, because in assembly you can make the second wave read active only during crossing to save CPU.

If it works as expected (with the on/off switching part), then I think this direction is worth to follow (then the start/stop points can be used without zero crossing finder). In fact it would simplify some things in my projects as well, because I would not have to make the loops on first place.

Okay, I need to do some VST checkups now, to see if the ASM'ed and reloaded from 305 to 304 version works as it should.

[KG_is_back]

In other words, if mono wave is loaded, then this value must be -4 (switch), yes?

Exactly! I forgot to mention that.

Mem pointer vs mem size, yes? Isn't it solved by the order of triggers, like in Exo's schematic? (attached below; I guess the amount of channels should be checked in the same way - first mem pointer, then channels).Anyway this part can be probably solved by either trigger order or sending values on confirmation triggers.

So the mem pointer outputs -1 if mem was not engaged? From what I've tested briefly it outputs random shit when you disconnect it or copy it.

OK here's the crossfade example: (note that it puts the crossfade on start where the indexing starts from zero again and puts in the stuff after the loop length):

By the way I've seem to found a bug related to wave file prim - when I click delete, the mem is not emptied and the previously loaded wave is still loaded in the mem (increasing schematic size) although the green outputs on the wave file prim state otherwise...

[tester]

I did the test with 8 minutes long, stereo file (glitchless loop), and VST export (no crossfade version; we posted in the same time) in reaper, to see if there might be any issues. Everything seems to work fine. Looping works fine, and no artifacts.

But I'm still wondering about the sound quality differences between interpolation methods done in FS, and exports made with cool edit or sony pitch shift. I tried to compensate it manually and quickly with these zdf filters, but there must something else going on, or the filters are very specific (maybe very sharp butterworths on the sampling edges? Need to check that).

[tester]

By the way I've seem to found a bug related to wave file prim - when I click delete, the mem is not emptied and the previously loaded wave is still loaded in the mem (increasing schematic size) although the green outputs on the wave file prim state otherwise...

Can't confirm that (304). And I load large wave files (200megs+), so it would kill the schematics. Maybe it's the "to int" (aka mem something in 305) prim?

[KG_is_back]

By the way I've seem to found a bug related to wave file prim - when I click delete, the mem is not emptied and the previously loaded wave is still loaded in the mem (increasing schematic size) although the green outputs on the wave file prim state otherwise...

Can't confirm that (304). And I load large wave files (200megs+), so it would kill the schematics. Maybe it's the "to int" (aka mem something in 305) prim?

No it is definitely the wave file prim, because when I delete the to int it does nothing and when I delete the wave file prim it deletes the file too (the schematic size drops to several kb as expected when no wave files loaded)