studiomux 5 beta

[easelec]

I also wonder if deleting the beta version and reinstalling might fix something. This is really odd.

[Vaultnaemsae]

This. Reinstalling worked.

I went through and deleted all remaining traces of anything Zerodebug related and reinstalled. This included the Touchable Pro and Studiomux servers. Restarted, reinstalled latest betas of both, allowed security permission for Studiomux, restarted again, confirmed plugins are installed and now we are off to the races!

I also reinstalled the beta iOS apps just to be sure.

I suspect, as I hypothesized before, that it was in fact something hanging around from the old Studiomux server/driver interfering with the current beta version…but who knows?

I’m experiencing good performance now. Tested the VST3 effect plugin with TH-U (iOS) against TH-U (MacOS) in parallel. Same audio input. And any latency is negligible.

Also tested the VST3 instrument plugin with OB-Xd (DiscoDSP) against the MacOS version and it’s performance is solid.

Bug wise: I had one loud audio pop, one crash triggered by duplicating a track with an SMUX plugin on it (this always happens) and a bit of a strange phenomena where the plugin seems to be trying to find the right sample rate — produced audio starts out about a tone above pitch and gradually slides down to meet the actual audio input’s real pitch. Also, suddenly lost audio a few time and had to restart the server, app and DAW.

N.B. Only tested with iPad Pro at this stage.

[easelec]

Great! That’s good news.

[Pascal]

Hi,

@easelec

Is it possible to open a MIDI effect AU (one that sends MIDI but not audio) in StudioMux directly that I am overlooking?

Not yet. I’m currently testing and implementing it, while trying to get the numerous non working AUEffects to finally work.

@iso

+1 for @Pascal to fix the sample rate & buffer settings selection before release. It’s been like this since day one of the Beta, & has been flagged on numerous occasions…

Will be fixed within the next beta, though i will exclude the samplerate setting. On iOS the samplerate is bond the hardware, as i understand i right. Up- or downlsampling will be done on receiver side anyway. (VST/AU, if audio is send from the mobile device/ studiomux app, if audio is send from desktop).

@Vaultnaemsae

I suspect, as I hypothesized before, that it was in fact something hanging around from the old Studiomux server/driver interfering with the current beta version…but who knows?

Thanks for trying out and good to hear that it finally works. Unfortunately we still have no idea, why a clean reinstall has this major impact on the functionality.

On windows, we will try to modify the installer, so each new install will properly clean all former installed files (this should already been done by overwriting the older files on install, but as you experienced, it obvioulsy does not).

On mac we would have to gave up the very convenient (for us :)) .dmg installer and set up a proper installer.

@Vaultnaemsae

Bug wise: I had one loud audio pop, one crash triggered by duplicating a track with an SMUX plugin on it (this always happens)

Will try to fix it within the next update.

@Vaultnaemsae

and a bit of a strange phenomena where the plugin seems to be trying to find the right sample rate — produced audio starts out about a tone above pitch and gradually slides down to meet the actual audio input’s real pitch. Also, suddenly lost audio a few time and had to restart the server, app and DAW.

The pitch/playing tempo adjustment is actually not only related to the receivers sample rate:

1. Each device has a unique cpu clock, meaning you will always have differences in playback tempo/pitch. For example: Your desktop will play 44100 samples in 1.00000001 seconds while your iOS device will play the same amount of samples in 0.999999 seconds.

2. Receiving audio from network and audio playback are procesing parallel, it is no serial process like:
   process1: receive audio -> process2: play audio -> process1: receive audio -> process2: play audio …

but a parrallel one: process1: receive audio -> receive audio -> receive audio
process2: play audio … -> play audio … -> play audio

To ensure audio can be rendered countinously, we have to keep a certain amount of samples in cache, .

The pitch adjustment you hear at the beginning is owed to the fact, that we want to minimize the latency (the number of samples in cache) as fast as possible, after starting the audio transmission: As soon as the audio receiver (Plugin/App) received samples from network, we start the playback (usually playback starts after the receiver got around 4 buffers from network). In case the number of cached samples is greater than 2.3buffersize, we increase the playback tempo to make sure the latency will be around 2.3buffersize at maximum.

Hope my explanation makes sense … In case it does not, feel free to ask. I attached the actual code.

When receiving audio, we calculate the clock_drift_addition value (one of the factors that determin the playback pitch).

if (cached_samples > buffersize * 2.3) {

clock_drift_addition = pow(((double)cached_samples - buffersize*2.3)/(16384.0*4), 1.2);
    }
    else {
        clock_drift_addition = 0;
}

Before pulling audio for playback, we calculate the number of samples we need to pull from cache (size_of_audio_needed), the clock_drift is derived from receivers/sender cpu clock relation):

        double index_change_per_sample = (1 + clock_drift + clock_drift_addition) * sample_rate_factor;
    int size_of_audio_needed = buffersize * index_change_per_sample + rest_of_sample_index;

Process of transmitting audio from mobile device to plugin:

1. we start sending audio from the device and notify the plugin that it may start to render audio.
2. the plugins sample cache fills.
3. as soon as the cache has enough samples, the plugin starts to render audio. when the plugin starts rendering audio it usually has more than 2.3*buffersize samples in cache. and the plugin has to increase the playback tempo (sweep) to adjust the latency.
4. as soon as the number of samples in cache is lower than 2.3 * buffersize, the tempo adjustment stops (it actually does not stop due to the clock drift, but the adjustment is not noticable. the clock drift is very small ~ 1.0001).

Hope i could at least answer most of the questions.

Best

Pascal

[iso]

Thanks Pascal! Great to see some of the inner workings & complexities of this beast of an app. I have always considered it to be practicaly a work of majic…I am always amazed that it works! Easily the most used, & useful app that i have…with AUM coming in a close second. Fantastic work! Thank You! Must be getting close to release? Have you tested with os15 Beta yet?

Again, many thanks for your perseverence & tenacity in re-writting the app for us. It really is apreciated.

[Pascal]

Hi,

@iso

Have you tested with os15 Beta yet?

Not yet, just installing it, unfortunately as Developer an iOS update usually also requires to update OSX and Xcode (both beta), which can pretty nasty.

@iso

Must be getting close to release?

Just wrote some sentences to the upcoming release:

Phone not detected

I actually planned to release studiomux at the 1st of August. Unfortunately, there are still a few tasks i could not yet finalize. The main reason that kept me from releasing the new version is the fact, that studiomux still works on devices running iOS < 14 and Mac’s running OSX < Catalina. A release would force them (when automatic app updates is active) to switch to the new version, that is a) not yet ready and b) was completey rewritten (new GUI/ plugin handling/ audio channel handling). Fo…

@iso

with AUM coming in a close second

AUM is the gold standard… i hope studiomux will become as reliable/stable as AUM… you may have noticed, that we also adopt some gui parts of AUM, just becaus we didn’t know how to do better.

Best

[iso]

AUM is undoubtedly the gold standard for functionality & reliability, everything I do on ios goes through it, but without Studiomux, I wouldn’t be able to get it out into an external DAW, (Ableton) without a lot of messing about. I guess that makes Studiomux the most vital component in this particular work flow.
Untill os 14 screwed it up, Studiomux was very stable & reliable, crashes were rare. I am sure Smux 5 can achieve the same level of reliability again, looking forward to the release…cheers…Mark…

[easelec]

Another AU that crashes while loading for me: Stratosphere Cloud Reverb

[Sr_Valasco]

Hi Pascal,

Any news on Windows? In my case, audio stopped working since version 5.091.

Thanks in advance.

[btvd]

Hey evereone! Joined beta and tested Studiomux 5 beta on Win 10 x64, Bitwig. I got evething working, but no audio signal from VST:

btw is there any way to route midi from Bitwig into iPhone 7 in my case?

Will appreciate all advices on how to make it run in Bitwig, win 10

[btvd]

Tested also StudiomixEffect vst, I could send midi data using it from Bitwig. I hear the voice on iPhone but still could not route that signal back into DAW

[iso]

Studuomux 5 released here in the U.K. Just gave it a quick spin. Working great, feels nice & stable.(Win 10, Ableton 11)

     Cograts @Pascal & the team. It Lives!

[btvd]

Glad to hear that! Hope Studiomux could be used in Bitwig also!

[Pascal]

Hi,

we successively released the app for devices running iOS 14 and above.

@easelec

Another AU that crashes while loading for me: Stratosphere Cloud Reverb

It crashes (does not load properly) here too. But for hell hell we cannot identify the root of the issue… But we are working on it,

Best

[easelec]

Maybe Blue Mangoo can shed some light?

Any luck figuring out why Timeless 3 isn’t working?

[Pascal]

Hi,

so… we found the issue, that caused many AUv3 effects not to load. It will be fixed in v. 5.115.

Update: I tested the latest beta v. 5.115 on several devices and for the first time i encountered an issue many of you reported before:

After updating from 5.114 to 5.115 it seems like parts of the old binary to remain on the device and the former issues remain. I had to delete the old App and reinstall the Update to really get it. This honestly exceeds my horizon…

Pascal

[easelec]

Does one only need to remove the app on the iOS side or on the desktop side as well?

[easelec]

The new version fixes a lot of issues. I am happy to report that all the AUv3 on the iPad that weren’t working before are working now.

A couple of things:

• in the iOS app, it feels like there needs to be a ‘clear session’ or ‘new session’ command in the Files popup so that you can create a new session from scratch if you have a session already open.
• I don’t know if this is expected, but on the Mac side (at least in Ableton), making any change in the Ableton audio preferences (such as adjusting the buffer size) causes the Mac plugin to lose its send receive settings

[btvd]

Hey, Pascal! Will check it out in Bitwig today, thanks!

[btvd]

I’ve tested new version, but still no sound in Bitwig 4.0.1 on Win10 x64

This is how SM vst looks like in my case in Bitwig:

It seems to me that eveything is ok here.

This is how it looks on mobile:

Should I try to route audio using Audiobus or AUM?