Establishing a hard upper note count bound per clip.

[twobob]

Doing some quick haze testing I noted that 909 notes appears to be the upper bound per clip.

Passing greater than this would cause the System.ArgumentException: 'Destination array is not long enough to copy all the items in the collection. Check array index and length. Arg_ParamName_Name' error pictured.

Can we confirm that 900 is a reasonable upper bound per clip and is there any situation where that value is further added to, that I have overlooked here. For example is this the total count of all notes passed in all clips for this one transaction? Just trying to establish if that is indeed the right place to drop in some defensive error-handling.

Many thanks

[twobob]

Turns out that one can accidentally bump into this when auto-scaling ratchets from arpeggios, I would suggest just discarding anything after /n/ hundred notes and warning the user.

[twobob]

600+ can be too many

[carrierdown]

Thanks for stress-testing this! I'll have to look into this a bit - basically the only limit should be the size of the UDP-packets themselves which are limited to around 60000 bytes. But I think maybe max for live's internal message length limit is lower, so it would be interesting to find out what the actual limit is here. As for mutate4l not handling a larger number of notes than around 900, I don't think there's a particular reason to limit this. Will investigate what the cause of this issue is. Thanks again 👍

[twobob]

Excellent, this opens the opportunity for it being used as a long phase harmony controller. 300 bars containing a few changes perhaps every 8 bars, each harmonic data chord being roughly 3->6 is size should fit neatly under those limits, permitting such long phase "overall harmonic control". Properly implemented and imagined that could be incredibly powerful alone. Thanks for the thing. I'll poke around if I get a chance and see what is bawking.

[twobob]

Fwiw, It appeared to be an error in the sizing of the actual data. I seem to recall it should scrape the command off the end ? and there was precious little for that to be on? which seemed odd?

You might know instinctively whats going on there, but that looked "just wrong" in the cases where the note data was so huge. Again, I'll investigate if it repros.

[carrierdown]

I've investigated a bit, and what's happening is that past a certain size (16384 bytes), the UDP message is split into packets. Handling this requires a lot of work, and would be better solved by using TCP instead which has a lot of this functionality built in. Redoing this will take quite a bit of work, and is not the first thing planned, but we will probably have to go down this route at some point. Having a limit on the number of notes per clip doesn't make sense really, since it would depend on the total number of clips. A better solution for now is just to check the total message size before sending from the m4l side, and send an error message instead if the formula+clips take up too much space.

[twobob]

right. makes sense. Anything to prevent this in the short term would make the workflow usable again. So easy to accidentally bump into this with real world songs. Thanks for the effort

[twobob]

For now: some real-world testing says 64 bar sections fall under the limit with a reasonable amount of content. As you can see pictured here. This workflow does not exceed the limits - currently. And provides long phase pitch "correction" https://gfycat.com/MinorJadedGander So. for now - do that in the real world (use 32 bar lumps on busy pieces with multiple passed control clips)

RE TCP: I see what you mean now. [sadam.tcpClient] | Bidirectional TCP client. [sadam.tcpReceiver] | Receive data from the network using the TCP protocol. [sadam.tcpSender] | Send data through the network using the TCP protocol. [sadam.tcpServer] | Bidirectional TCP server.

Got it

[twobob]

Fwiw, Accidentally 128 bars of drums down it again today and it did not fail elegantly - just so you know later I weighed half of it - probably would have been 22kish of data.

I did note some extant scaffold code, must not have fired. EDIT okay that was if (formulaAsBytes.length > 16384) ... in the JS of course. guess it never got that far

EDIT: Yeah big stuff still silently fails