MXJ Searchtweet GUI glitch
Hi everyone!
I'm working on an interactive A/V project using Max 8.1.11 and Live 11.0.2 that relies on GOKCE KINAYOGLU's brilliant Searchtweet patch: https://cycling74.com/tools/searchtweet-design-patches-that-respond-to-twitter-posts/
I've input my own API keys from Twitter and constructed two Max for Live devices that utilise the search Tweet functionality as intended. I have ensured they do not exceed Twitter's API call limits (300 per 15 minutes using the GET function).
The problem is that whenever these devices make an API call, Live's entire GUI - and, crucially, the visual output from Jitter, whether viewed in a Jitter window or output via Syphon - pause momentarily. Audio is not interrupted and there is no spike in Live's CPU meter. Live's transport visually stutters.
All other applications are quit and I was unable to identify a source of the glitch outside Live in Activity Monitor.
So far I tried:
updating Twitter4j to 4.0.7 - this caused Console errors, had to revert to 4.0.1;
updating Java SDE from the Cycling 74 recommended 8 to the latest (16) - no difference, same glitch, reverted back to the recommended version; and,
removing all unnecessary GET functions - no change in performance there either.
I have also tested other people's devices using the Searchtweet mxj object and they produce the same pause to Live's GUI: all running parameters (transport, etc.) visually stall out for about one second without impacting audio. I also tested these devices in Live 10 rather than 11 and in projects in both Live versions without any Jitter objects and they cause the same visual stall-out.
This is all running Mac OS X 10.15.7 on a fairly high-performance MBP: 2.4 GHz 8-Core Intel Core i9, 32 GB 2667 MHz DDR4, with an AMD Radeon Pro 5500M 8 GB GPU. I've tried using gfx.io to restrict use to the AMD GPU only but it doesn't seem to make a difference either.
Internet connection is hardwired via ethernet cable, measured at 60 mbps download / 10 mbps upload.
If this were an audio-only project it wouldn't be an issue but the visual component is critical and these hiccups aren't acceptable. The visuals are running perfectly whenever the Twitter API isn't engaged.
I'm fairly comfortable with Max/MSP but admittedly don't really have any Java skills. I know I'm using Live but the issue is clearly with mxj, hence the post in this forum.
If anyone has any ideas on resolving this, that would be amazing!
Thanks for reading.
the best advice I can give you is to extract the Jitter elements out of your project, place them in a separate patch, and run that patch using an instance of standalone Max. create hooks using udpsend/udpreceive for any UI elements (or other controllers any your main patch) to the relevant Jitter parameters/messages/attributes.
I would create a simple test project first to verify this fixes your stutters before fully committing. happy to advise further on how best to achieve this extraction and synch on your project with more details, or issues you run into.
it's also possible using something like node-for-max there may be a solution that doesn't stall the main thread, but in general for these types of projects running Jitter in its own process is going to give you the best results.
Thanks for the swift response Rob - I'll definitely experiment with this!
However, just to be clear, it's worth noting my Jitter output runs absolutely fine as configured - so long as I don't ping Twitter's API via the MXJ patch.
I would share the devices here, but don't want to give away my private API keys. Let me know if you'd like me to send it to you via email.
Hi Rob ,
It became abundantly clear that the issue was with the MXJ object and not Jitter. Furthermore, this project relies heavily on tight integration between Live and Jitter that would not be possible over UDP.
However, inspired by your suggestion, I managed to sandbox the MXJ Search Tweet in a separate maxpat running outside of Live's thread, sending and receiving intermittent (non-continuous) ints and floats via UDP.
Thankfully this seems to have resolved the issue with Live's GUI and Jitter output stuttering!
Unfortunately, the sandboxed maxpat often freezes of its own accord, which I can observe in Activity Monitor. This happens without any CPU spike or outsized network packets, but nevertheless takes the functionality offline - deeply suboptimal.
I have attached a version of the .maxpat here with my API keys removed; I'm using the Cycling74-recommended Java 8 with the searchtweet.class and twitter4j lib folder installed to Shared/Max 8/Library as instructed with the materials here: https://cycling74.com/tools/searchtweet-design-patches-that-respond-to-twitter-posts/
All its receiving via UDP is the int "1" banged in every two bars from Live at most.
Do you think you could take a quick look and let me know if there is anything obviously wrong with the patch?
Many thanks!
Update: since restarting my machine the above patch seems to be working smoothly - hopefully the performance quality holds..!