heavy icon indicating copy to clipboard operation
heavy copied to clipboard

[hv_table_resize] might not be working correctly

Open owenhindley opened this issue 9 years ago • 13 comments

In our PD patch, we have a table with an explicit length of 604800, which we're using for a looping sample. These lengths are set to accommodate the sample at 44.1Khz = 604800 samples.

When our project is running on a platform at 48Khz, we're loading in an upsampled sample which when played sounds correct, but is longer at 658000 samples, and the loop gets truncated at the end.

Shouldn't hv_table_resize be taking care of this, and expand the table size to the required length?

Or do we need to pre-set our tables large enough to store the maximum sample rate that our patch could conceivably run at?

owenhindley avatar Aug 12 '16 17:08 owenhindley

as a side note, when we resize the table to 658000 samples, we get correct looping :)

owenhindley avatar Aug 12 '16 17:08 owenhindley

Is this in unity?

mhroth avatar Aug 12 '16 17:08 mhroth

Sorry, yes - Unity / Android + OSX.

owenhindley avatar Aug 12 '16 17:08 owenhindley

Are you calling FillTableWithMonoAudioClip?

mhroth avatar Aug 12 '16 17:08 mhroth

FillTableWithFloatBuffer - which I can see has a call to hv_table_resize

owenhindley avatar Aug 12 '16 17:08 owenhindley

And how are you looping in your patch? Is it with [tabplay~]? Or some other mechanism?

mhroth avatar Aug 12 '16 17:08 mhroth

@ylevtov wrote the patch, but it's played back via s_playtable2. Looping's handled via a bang every 8 bars (or so) which comes from a central timebase.

owenhindley avatar Aug 12 '16 17:08 owenhindley

There is an known issue where certain objects don't update their knowledge of the table's length when hv_resize_table is called. Potentially you're running into this issue, and not that the function itself doesn't work. Ideally we could get some feedback from @ylevtov about his implementation and see about fixing the issue if possible.

mhroth avatar Aug 12 '16 18:08 mhroth

@mhroth is correct, the table is updated, but the tabread isn't.

@owenhindley directly after your call to FillTableWithFloatBuffer, I suggest you send in a message to a receiver to set the s_playtable2 playback length manually.

diplojocus avatar Aug 12 '16 20:08 diplojocus

@owenhindley I'm mark this as solved, unless there's still some issue you're experiencing.

We've got a ticket to properly implement table resizing but for now the workaround is to mainly send the resize message into the patch.

diplojocus avatar Sep 20 '16 09:09 diplojocus

I'm having a similar issue. I I use (float)_clip.samples; to get the audio clip's amount of samples, Unity gives the samples in the rate of 44,100 Hz, but when I press play the resulting printed values and sound indicate a samplerate of 48,000 Hz. The op mentioned "hv_table_resize", but what is that? I don't see it on the list of Heavy-compatible abstractions: https://github.com/enzienaudio/heavylib

diemildefreude avatar Mar 27 '17 09:03 diemildefreude

@diemildefreude would you mind making a separate issue for this?

diplojocus avatar Mar 27 '17 10:03 diplojocus

@diplojocus Not at all.

diemildefreude avatar Mar 27 '17 10:03 diemildefreude