Dynamic Table Size ?

[TobyAM]

I have a seemingly simple vanilla PD patch that gives no errors upon uploading to Enzien, but the patch doesn't play back recorded audio properly in the Wwise plug-in.

https://enzienaudio.com/h/TobyAM/TapeMachine/

I've read things here able table resizing issues that I don't understand fully. Is table resizing my issue here?

I hope this kind of general call for help is ok. I'd love to get this to work!

[diplojocus]

Just having a quick look through your patch, one thing I know isn't supported to sending messages to arrays/tables. Heavy only implements generic send/receive, i.e. sending to receiver of the same name. So you can't really send messages to objects like you're doing.

The following won't do what you expect:

[resize $1 (
|
[s array1]

It will just send a message say resize 60 to a [r array1].

Thinking about it, this is probably the issue. Your default table size of 0 means that nothing will happen in the [tabwrite].

In r2017.01 I actually rolled out a so far undocumented feature for loading samples into tables in Wwise. Do you want to store an incoming stream, or to preload a table? If it's the latter you're welcome to try this feature out.

You can expose tables by doing [table myTable 100 @hv_table] in the same way as you expose RTPCs.

This will create a button in the authoring plugin interface where you can load .WAV files from your drive, which Wwise will store and load into the plugin whenever it's played.

When the table is loaded it will also send a message containing the new size of the table to a receiver called [r setTableSize-{tableName}] where {tableName} should be replaced with the name of the table, in this case [r setTableSize-myTable].

I'm still ironing out some bugs so it's probably best to test with one table for now.

Hope that helps!

[TobyAM]

I see, thanks for the info! I am actually trying to store an incoming stream, as I want to be able to sample and playback the affected audio with varispeed. Ever played Braid? I have a similar rewinding task.

So I removed the messaging to the tables (and table resizing altogether), and tried a set table size with an attribute, which still doesn't seem to work (compiled and no audio from table).

[diplojocus]

Yeah I know what you mean!

Hmm, thinking about this more, it might be better to pre-allocate the table to your biggest size you ideally would need, that way you aren't constantly reallocating memory every time you record.

How are you triggering the recording stage? Are you sure it's correctly trigger the tabwrite~? I'll see if I can take a look tomorrow.

[TobyAM]

Hey, that occur ed to me too, so I went for the largest table size I could think of before going into scientific notation (wasn't sure if that was causing an issue), so 999999 or about 20 seconds at 48K.

I've attached a screenshot of the patch for reference. The tabwrite~ is triggered like so

[r OnOff @hv_param 0 1 1]	[toggle]

[sel 1 0] | [s recording]

[r recording] [tabwrite~ array1]

If you have any more time to take a look that would be amazing!