Poly Slicer V1.0 Alpha

[tulamide]

Can you share the file for me to test?

Of course, here you are:

100bpm_24bit_loop.wav on dropbox

[Exo]

Update!

*Loop points are now read correctly.
*Loop, Follow pitch and reverse are now set per note (slice) when in polyphonic slicer mode.


@tulamide the loop points were inside the sampler chunk, it was a minor error on my part. When skipping some data I wasn't bothered about I skipped a few bytes to far

[tulamide]

Hehe, that happens. That's what testers are for

I will have a look at the new version tomorrow!

[Jay]

Hi Exo

been following this lately. it crashes flowstone now for me on loading a wave file!

cheers

[Exo]

Hi Exo

been following this lately. it crashes flowstone now for me on loading a wave file!

cheers

Thanks for reporting

Yes there is a problem, I was testing with a file that had loop points in and it seems ones that don't can either crash or don't load properly.

[tulamide]

Exo, I am not very advanced in C++, so I might give hints that you've already taken care of while I didn't notice from reading the code on GitHub:

1) data chunk, the cksize field contains the length of the sampled data. But it excludes the pad byte that is added, if cksize is odd. (cksize = 23 means 24 bytes [23 + pad byte], cksize = 24 means 24 bytes, etc.) Ignoring the pad byte might set file cursor to offset positions!

2) smpl chunk, again the chunk is padded, so check cksize for being odd or even and append 1 if odd.

If I find more, I'll report. And if you've already taken care of the above and I was just too unexperienced in C++, I beg your pardon

EDIT: Found an interesting format description, that could supplement yours. For example, this is from the link

The dwIdentifier field contains a unique number (ie, different than the ID number of any other SampleLoop structure). This field may correspond with the dwIdentifier field of some CuePoint stored in the Cue chunk. In other words, the CuePoint structure which has the same ID number would be considered to be describing the same loop as this SampleLoop structure. Furthermore, this field corresponds to the dwIndentifier field of any label stored in the Associated Data List. In other words, the text string (within some chunk in the Associated Data List) which has the same ID number would be considered to be this loop's "name" or "label".

http://www.blitter.com/~russtopia/MIDI/~jglatt/tech/wave.htm

[Exo]

Thanks tulamide, indeed I have overlooked padding bytes. This sounds likely to be the causes of the problem.

Interesting to read about the Cue Chunk , thanks for the link.

[tulamide]

@Exo

May I ask a few questions? I wonder how exactly you wanted the user to handle this VSTi. From my tests I have the following impressions:
You hit a key and then make changes using the UI. You hit another key and again make changes. If you hit the first key now, the changes related to that key are loaded and presented, if you hit the second key, the changes related to the second key are loaded and presented. So, changes are related to the last key pressed.
One of the options is to set a loop to "follow pitch". That is also loaded and presented on a per key basis, but if you set key 2 to "follow pitch" it plays pitched, if you then additionally press key 1, which isn't following pitch, both are played without following the pitch.

1) Is follow pitch meant to be only per file? If so, why can I change it per key?
2) I think it isn't intuitive enough, but just because of a missing user response. You can't see if the poly slicer has noticed that I want to make changes to key x. Shouldn't it be more informative, with an extended UI?
3) Which of all the options poly slicer offers, are meant to be changed per key, and which ones per file only?

The reason for asking is that I'm currently working on a complete overhaul of the UI. Not just skinning, but also a catchy name, a cool logo, a proper color management (those three already done), and I want to make the UI more accessible, so that the user gets the most out of the VSTi. I have quite a few ideas of how to do that, but since I don't know exactly your intentions I better ask first. Also, I have quite a few ideas for features this tool should have. But that's something I can present as a demo GUI, once I'm certain about the direction you want to go.

[Exo]

Thanks for getting involved tulamide

The changes I made for per note "follow pitch" , "loop" and "reverse" are actually only implemented on the UI side, I forgot to implement the audio changes necessary

I think maybe "follow pitch" should just be per file, "Polyphonic slicer" mode is obviously per file , so just Loop and reverse per key.

Yes a more extended UI would be good, the user does need more notification which slice or key they are currently editing.

I'm happy for you to showcase whatever you think is best for the UI, I want to make it as simple as possible for the user to use. There is definitely major room for improvement

[Exo]

OK so now the crashing on load is fixed.

It wasn't a problem with padding bytes. It was a problem with the sampler chunk, I forgot to read "samplerData" variable after the number of sample loops. I was also reading the values in as 'int' when they should have been 'long'.

The code should be much more robust and stable now. I correctly check for and skip any padding bytes. I now read the format chunk correctly, before I assumed it was always the first chunk. I also check to make sure the Format chunk comes before the data chunk.

Change list...

*Crashing on sample load fixed
*Follow pitch is per file again.
*Loop and reverse work correctly in polyphonic mode.

Issues..

*Reverse only seems to work when Loop is on.