Hi,
maybe offtopic...

Why does TMFX not send any MIDI Data of its OUT Port if i move any of the Faders via Mouse in the TMFX App?
The TX LED does not blink... Even if i try any other MIDI Hardware for TX

The MIDI IN Port on my FF802 works fine from my Controller. The TMFX Faders move if i send the corresponding CC Mesages. And the RX LED blinks...

https://ibb.co/KbBNMTm
https://ibb.co/34xKLQS
https://ibb.co/47gVDGj

From TMFX Help:

MIDI Remote Control
   • MIDI In. Input where TotalMix receives MIDI Remote data.

   • MIDI Out. Output where TotalMix sends MIDI Remote data.

   • Disable MIDI in background. Deactivates MIDI Remote Control as soon as another application is in the focus, or when TotalMix has been minimized.

Did i miss something?

Hi, are you on a M1 airbook too?
Loopback sadly don't works for me since I need the physical inputs as fx returns, and without the main fx I don't need to monitor the master signal, so the future feature is highly welcome for me.. especially because of the goniometer...thats what I mainly want to see in the sum when mixing down strange fx arrangements.
greets.

I installed the driverkit 4.04 driver on my macmini 2018, 3.2ghz 6 core i7, 32gb ram, Monterey 12.5 with the Madiface XT, latest firmware.

The driver installed fine. I was asked to allow the driver and after a restart everything was up and running.

However, Madiface XT was only recognised when in usb2 mode. In usb3 mode the device was not recognised and not functional. With the old driver, Madiface is recognised in usb3 mode, but I get a lot of up to 5 seconds long dropouts. Since I currently only need 64 channels, I'm running the device in usb2 mode.

Nuendo 12.0.40 recognised Madiface without creating an aggregated device.

I had to reassign audio connections in Nuendo and the Audio-Midi Setup (speaker setup).

Load in Nuendo in a fairly heavy project (44.1khz, lots of VIs, plugins) at 64 samples latency was the same as with the old driver.

Load of the driverkit driver in activity monitor was about 15% with said project playing, aroung 12.5% when playing a youtube video, around 8% when playing apple music and 1.5-3.5% when idle.

When playing back music without any other activity, the ram usage is getting bigger and bigger. It's mainly the window-server that's eating memory, about 500mb in a hour. I have not compared that to the old driver yet.

I will observe further and try my macbook pro 14 next.

Hello, I'm sorry I hope not disturb. I'm not sure if it's related to this driver. But I just got this message from my iOS https://support.apple.com/en-us/HT210999
I have a Mac M1 Max with a Fireface 802. Please advise if I'm in the right thread. Thank you!

I re-did my test, but this time with Activity Monitor closed. After two hours of music playing, memory usage was not increased. Then I re-did the test, this time with Activity Monitor open again and memory usage was increased again. Thus, this is probably more a problem of Activity Monitor and not related to the driver.

Hmm. Unfortunately this easy fix won't work for me. I mostly do not open or use the activity monitor. The first time I used it was because suddenly after installing beta driver my Mac Mini did not have enough RAM to handle the tasks he could handle before. Like I described it pops up a message that programs have to be closed in order to work further. But the message reappears no matter how many programs you close. I only opened the activity monitor to prove my point (does not matter how much is open) with screenshots. But I have the impression, that this bug (triggerword!) is not taken that serious from official side. MC might prove me wrong – hey c'mon you like to prove someone wrong – please do it! ;-)

Another kernel crash today with beta driver 4.04, now updated to macOS Monterey 15.5.1 (on the M1 Mac Mini).
Panicked task: de.rme-audio.dku
Still no crash dump on disk to be found, but I copied the content of the Apple problem report dialog and sent it in to support@rme-audio.com

Do you generally reply to mails sent like this, or not?
I've sent 4 different logs, but I'm not sure if any of them arrived in the support inbox, or if all of them were stuck in the spam filter?
If they're getting through, if possible, just give a heads up in the thread, and I'll continue providing them.

I forwarded it.

Thanks for confirmation, then I know! Important thing that you received at least one of them.
I'll hold off reporting any additional ones unless there's a clear change in pattern on the stack trace, or a new driver version is released or similar.

Looking at TotalMix (and DigiCheck) it should be clear what happens here: the number of MADI channels shrink from 192 to 96. Analog I/O therefore is now found on channels 97/98, the higher channels are no longer used.

We will change that in the upcoming 4.05 so that the 'behind MADI' channels stay on their channel number.

Ok...I found out that Logic Pro can be OSC controlled via a Script located in /Library/Audio/MIDI Device Scripts/...

From the MASCHINE MK3 OSC.device:

--[[ Requirements for OSC Profiles
For OSC Profiles, there are only three functions to be implemented:
* `controller_info`: as with any other MIDI Device Profile, provides a default assignment list, just as for other control surfaces, and also the pattern recognizing the device (`OSC_pattern`)
* `CSFeedback`: doesn't send any feedback; returns a non-null value for the maximum length of text feedback.
* `CSLabelSize`: returns the maximum length of a text label, if there is one for the assignment.

All OSC communication is done by Logic Pro — you don't have to write it.]]

This is a first point to start...

I am seeing this exact behaviour.  (GUI interaction, system sounds, etc etc)
Even a message notification sound will set it off. (I'v disabled notifications, but the "alert" sound trigger seems to set it off, even when routing them through the Mac Internal speakers.
Sometimes won’t hear a dropout, but it affects DAW buffers after.a few seconds. 
ProTools ultimate will throw 6101 error and stop (even when no plugins or even with video engine off)
Logic will glitch. (audio dropout, or CPU error... with hardly any CPU use)

I can make it happen just by taking a Screenshot via Command-Shift-3.  It will glitch several seconds later.
Something is a miss.

It’s really doing me in.

Going to have to go back to 3.74 at this point.  (will report back if this doesn't fix it).
Must be worse with MacOS 12.5.1 as well in my experience

This is on Mac Studio Ultra.

Ok, so after re-installing v3.27 I am still getting for example DAW errors when an alert sound occurs, so I am thinking something has changed with OS12.5.1

****EDIT:  I've since discovered it was an AVID audio driver (Library/Audio/Plugins/HAL/ "AVID audio driver in here"

4.04 working once again.

New situation, that have happened before also with 3.27, but is not that common.

Do:
I try to play a wav-file, an m4a-file in Finder or a youtube video, or basically any media anywhere. When this occurred just now I was playing an audio file inside Trello and listening through my headphones that are connected to my RME Babyface.

Happens:
Nothing. I can't play anything. All media is as if frozen.

Expected:
To be able to play back media, any media.

How do I know this is at all related to the RME audio interface is that when I disconnect it and wait for a while, a long while like a minute, and I try to select another system audio output, this is at first not leading to anything. Finally, when the Babyface option disappears my selection will finally kick in and system audio, not via Fireface, works again and all playback is functional.

I found a crash report named "RMEUsbAsp" that would seem related to this issue. Full log at pastebin.

Further symptoms is that I seem to have to restart to get Fireface back running. This is what I get when reinserting the USB cable (USB-C to USB-B):

default    00:50:29.030786+0200    kernel    Kext de.rme-audio.driver.RMEFirefaceUSB is not loadable
default    00:50:29.030806+0200    kernel    Kext de.rme-audio.driver.RMEFirefaceUSB failed to load (0xdc008013).
default    00:50:29.030813+0200    kernel    Failed to load kext de.rme-audio.driver.RMEFirefaceUSB (error 0xdc008013).

Are you still using an UFX? Is that one on the latest firmware USB 361, DSP 163, FW 344, Class Compliant 29? Your computer model? Any errors listed in the display?

https://forum.rme-audio.de/viewtopic.php?id=33684

Switching the UFX Off/On should help quicker than rebooting the Mac.

On MacBook Pro M1Max with Ventura OSX is working fine!!

So when playing a track in the Apple Music app these are actions that can cause a short dropout, with which I mean an obvious deviation in sound, not silence:

• starting a web browser

• starting a Spotlight search

• quitting an app

• Not doing much but listening to the music

I see no indication of memory pressure or overloads. Dropouts last for a very brief moment.

Today was the first time I heard such a dropout in my DAW. It happened just once though in an hour long session.

After now having not used my RME audio interface for a few days, there have been zero issues like the one above. This is strongly suggesting the issues Ive experienced are linked to the 4.04beta driver.

Do RME need any more data that I can help you with, @MC?

After using the 4.04 driver for a couple of weeks, I had roughly once a week the issue that after booting up the computer all audio is heavily distorted, regardless if using the daw or just playing music from itunes or youtube. The issue either goes away after a couple of minutes or requires a reboot. No error message is displayed.

It might have to do with spotlight or sync services working in the background after boot.

That's fixed already, but thanks:

https://forum.rme-audio.de/viewtopic.ph … 00#p191800

Are there any updates on the status of the driver?