Wrapper: add readdump message

[weefuzzy]

To make up for breaking read,dump sequentiality

This goes through the Max API to glue the two messages together, because otherwise there would have been disproportionately terrible template shenanigans

[tremblap]

I'm thinking now about this, and I wonder what is the usecase that would not be fulfilled with reading the same file in parallel in a dict and in a FDS?

[weefuzzy]

You lose the convenient confirmation that the data has been loaded into the dataset to your satisfaction.

Also, to gauge the extra faff, think about which repeated change you'd rather make to all the help file examples for the dataset related objects that use read, dump

[tremblap]

ah your convincing arguments :) obviously that will have to be done as part of this pr and it will be painful...

another PR that will also need to happen is one in docs with the max_only flag, whatever its syntax, to explain this method and also add a line to read and write being deferred at the lowest rank of scoundrels...

[weefuzzy]

Help file updates is a simple regexp replace, although running the regexp reveals that there's only actually 5 instances where we do read, dump like this. There are also 2 where we do read, size, which I would be less inclined to make a new message for.

So maybe it's not worth it after all.

[tremblap]

I think that if it helps advanced users to avoid a loop to check status, it might be worth a road test. Let me see how the doc reacts...

[weefuzzy]

re the docs – documentation for read, write etc are in the max xml template, so that would be the place to add this.

https://github.com/flucoma/flucoma-docs/blob/7809832e999bf64df88b9b02e1236779914296b5/flucoma/doc/templates/maxref.xml#L101-L117

[weefuzzy]

Actually, I've just thought of an oversight in all this, which is to do with what gets spat out of the dump outlet after the message has completed. At the moment you'll get read then dump, which is silly. Making it less silly is harder.

[tremblap]

2 pragmatic options:

1. if the readdump was part of the framework (and not just max) would that make this easier? For instance, in SC that could avoid read/write/read as dump writes and reads...

2. we forget it for now and warn our max users that they have to wait for read to confirm, like buffers do iirc

I'm opened to plan 3 - the ugly double message solution for now - to see how we freak on the nightlies... but that is a dangerous precedent :D

[weefuzzy]

It wouldn't make it easier, no. Or rather, it would introduce different difficulty.

I'm minded not to bother with this for the time being. I thought we were relying much more heavily on read, dump in the help than seems to be the case. Instead, we should just fix up the help files.

[tremblap]

ok I'll need to add a message in the doc and fix the helpfiles indeed with the deferlow merge, I'll do a PR for the discipline

[weefuzzy]

Ok, cheers. If you haven't already found them, help file bits to fix:

• kdtree
  • 1 x read, dump
  • 1 x read, size
• umap
  • 1 x read, dump
  • 1x read, size
• mlpclassifier
  • 3 x read, dump

[weefuzzy]

Think something like this is the least messy way:

[tremblap]

it is indeed... I'm drafting careful words for the docs now which will be of more consequence I think