MOTUnation.com

We just hired a second audio editor to work on our TV and radio broadcast projects. I've always used DP with my projects stored on local drives and it's worked great. We are now trying to save our projects to a network-attached storage drive on our Mac AFP server and running into some issues. Primarily:

If I create a DP project on the server, I have no issues editing it over the server connection. If my second editor tries to work on the same project, when saving the project file, he gets the following error in DP: "OS error: There is no such volume (-35) Try to save your file on another disk or folder, or with a different name." Some functions in his session are also not working or cause crashes, most notably trying to time compress / time expand a soundbite.

Our video department routinely shares Adobe After Effect projects over the same server with no problems.

I'm just wondering if anyone has any suggestions or has encountered similar issues. Thanks in advance!

Dave

Each user needs full read and write privileges to the files on a remote drive.

Find the DP project folder, run Get Info. You'll see that you are an admin and have Read & Write privileges. Other users must do the same, then highlight the line and check the box for Apply to enclosed...

This may have to be done for every Name in the Privileges box.

Hopefully, it's this easy. Sometimes, network issues may prevent this.

I'm not sure if this is sufficiently similar to the discussion to go here, or if I should start a new thread. Issues using network server (local site 1000baseT LAN, no WAN, internet, nor VPN) yes; but *not* involving multiple users as presented by the OP.

In a nutshell, studio procedures here have recently made it strongly desirable to work projects on a studio LAN. The mount is fine, all permissions are fine, and ANYTHING and EVERYTHING other than DP (currently running 9.52) has no problem whatsoever in reading and writing files, directories, etc. across the network mount. DP however will *read* the project happily, but refuses to *write* anything back out to the network mount.

I have opened (and later marked closed) a ticket with MOTU, the final word from which was that DP is actually *designed* to not write across network mounts, in order to assure the highest likelyhood of success. Really? In today's networked world, and the prevalence of high-capacity facilities that rely on large LAN mounted storage devices, DP cannot write to network mounts? I thought I'd ask here to see a) if that really is a valid answer, and b) if it is, does anyone know of a decent workaround?

The workaround I am using at present is to simply copy current projects to a locally mounted USB3 drive, work the projects there, and then use the terminal to 'find <options> <USB3drive> | cpio <options> <networkdrive>' to update all-and-only the changed files back to the network instance. That works fine, but it would be a lot more convenient if DP had a way to write the network mounted project directly.

Thank you for any insight/ideas to help solve this.

Been awhile but... any update or new info on this? I'm shocked to hear that Performer will not (or is not intended to) work with NAS mounted volumes.

I'm having problems using Lite with projects stored on my Synology NAS. If I record audio in these projects, an error pops up saying "Files are on different drives" and lists the intended .wav file it is trying to create plus the temp .wav file in the system temp-items directory (Mac). The project file itself will save to the NAS just fine, but no recordings will. Permissions are all solid, and I have no issues reading or writing to the NAS with any other applications.

Macbook Pro
MacOS 10.14.6
Performer Lite 10 and 11

Wow, I'd almost forgotten I had posed the question. Unfortunately, the facility where we wanted to do that no longer exists and I haven't had an opportunity to attempt it again since then. I suppose I should set up a private LAN with a NAS and try it again to see what DP 11 can do.

That said, I noticed you mentioned using performer light version 10 and 11, and I know there are some differences between performer light and the full version of digital performer which is what I am using. I do not believe access to storage should be any different between the two however.

Reviewing some details in the actual original post, the behavior he describes strikes me as being what I found as well, the project file can be on any drive, but active recording is restricted to locally attached drives. I think I will set up a test scenario to see if that has been relaxed since whichever version I was running back in 2019.

Yep.

When recording to a directly attached hard drive, in this case via USB, the temporary files are stored in the temporary location on that drive, and when recording is finished they are renamed into the project space.

However, when trying to record to a network-mounted drive, while the project file is on the network drive just fine, the recording is placed into the temporary space on the MAIN SYSTEM DRIVE, ie root, and therefore when recording is finished the file cannot be simply renamed into the project space, because just as the error message indicates it is on a different drive.

This gets into file system management issues, were renaming a file simply changes its directory entry without actually relocating the blocks of the file (and trust me, we want it to work that way). But when a file is on one physical drive and you want it on a different drive, a simple rename cannot get it there. This is not a fault of Digital Performer, it's just a characteristic of how file systems work. That said, DP is not even attempting to record audio onto a network mounted drive, and when you try to do so, it is defaulting to the only reliable non-network location it knows: the root volume.

So the short answer is, Digital Performer will not record audio directly to a network-mounted location.

So what is the solution then? I've been looking into NAS systems lately, and I mostly plan to have it hooked up directly via 10GbE or TB4 to the Mac here. Does a direct non WiFi based network storage solution also run into this issue or can I set up the NAS to read/write via TB etc. like a DAS?

Oh and obviously the solution isn't pretty but downloading then overwriting the copy on the NAS is a way to get the files in and out of the NAS I guess.

Hey, Michael!

I am not sure if an actual NAS system presents itself differently as far as the OS or DP are concerned. My available test environment is simply an old Western Digital network-mountable drive on my LAN (internally running some form of embedded Linux actually). I wonder if Glenn or Adam would have a little more insight into using network storage with DP, or if it would be a reasonable question to pose to Matt on Friday..?

Michael Canavan wrote: ↑Thu Feb 03, 2022 3:02 pm So what is the solution then? I've been looking into NAS systems lately, and I mostly plan to have it hooked up directly via 10GbE or TB4 to the Mac here. Does a direct non WiFi based network storage solution also run into this issue or can I set up the NAS to read/write via TB etc. like a DAS?

Oh and obviously the solution isn't pretty but downloading then overwriting the copy on the NAS is a way to get the files in and out of the NAS I guess.

I'm guessing but I suspect that you're good with a direct connection either way as long as the NAS is fast enough (4 or more HDDs RAID 0 or SSDs). Apple used to advertise in 2018 that you can harness multiple Macs with a T2 and 10GB Ethernet to make a supercomputer. You don't see that since the MP 7.1 in 2019 but you can still do it. WiFi, even 5G, isn't fast enough (someday?) and Apple says it doesn't work over 1GBE — I've always figured that speed is the issue.

If I understand the answer you're giving involving speed of the link between the computer and the NAS (and you present some very cool ideas there, to be sure), I should clarify that the problem in this case is not the Mac being able or not to access the network mounted drive with sufficient speed, that stage is perfectly fine. It's that Digital Performer as an application package is apparently designed to not *write* audio live to a network-mounted destination - playing from there is fine, recording to there is not. Now a faster network (10GBE or more) or a different connection type (e.g. TB vs Ethernet on an RJ45) might change the playing field, I do not know. My local LAN is only 1000baseT (1GB) as is the old network drive I am using in my tests.

But regarding changing the connection type, I've been out of cutting edge systems admin for quite some time, but I would think that if the connection type changes from Ethernet to thunderbolt, the NAS is no longer technically "network-mounted", isn't that right? If so, then connecting the NAS via TB eliminates the whole network question entirely.

But when the only option is to access a particular drive via the network, we are seeking a solution or work around to access that drive to record new audio through Digital Performer. It seems the best work around I have seen so far, which is exactly what I used to do with that system back in 2019, is to have a copy of the current project on a local drive, do the recording in that area, and then use system utilities such as cpio to synchronize the working space with the network mounted long-term storage space.

kats_corner wrote: ↑Fri Feb 04, 2022 5:59 am But regarding changing the connection type, I've been out of cutting edge systems admin for quite some time, but I would think that if the connection type changes from Ethernet to thunderbolt, the NAS is no longer technically "network-mounted", isn't that right? If so, then connecting the NAS via TB eliminates the whole network question entirely.

This is the big mystery, Technically NAS bays all use a network protocol, so even the Qnaps with Thunderbolt are converting the port internally from 10GbE, every TB NAS also has 10Gbe. It's totally possible the Qnaps that have built in TB work fine with DP, and even the 10GbE systems with a converter dongle for Thunderbolt work as well. It's also possible it's not any better.

I'm sitting here debating between a 9 Bay mixed environment 10Gbe system and waiting on the 4 bay Thunderbolt 4 Qnap that got announced last month. Whatever I buy I'm goign to have to look into the return policy, it's possible for what I want to do a NAS is not the solution and it's just better to get a DAS.

Well, I think I found a workaround for recording with DP projects located on a NAS. Using DP's "Audio Monitor" panel, you can re-point the "Take Folder" of any given record-enabled track. If you re-point to a folder on the system drive (maybe even on a directly attached external drive), Performer appears to be happy. When you're done with the recording session, copy the fresh record files to your project folder on the NAS. Your project will still be expecting the audio files in the take folder on your system drive. So go to the clips panel in Performer and repoint the relevant clips to their corresponding audio files on the NAS. Then you can delete the audio files from the temporary take folder on your system drive. It's a little tedious, but it seems to work without errors popping up or audio files being lost.

Note that I'm using Performer Lite, but I'm pretty sure this works the same/similarly on the full DP as well. In Performer Lite, I have to use the "Audio Monitor" CLI command to pull up the Audio Monitor panel, as there does not appear to be any menu option or button to do this (not that I've found yet, anyway).

I'm still stumped as to why this basic file management is not built-in to Performer. Seems pretty straight-forward to me: If the take folder is located on a NAS, ask the user to select a different (locally attached) volume for temporary record files. As soon as the record-head stops, copy/move the temporary audio files to the NAS-based take folder in the background.

mikehalloran wrote: ↑Thu Feb 03, 2022 6:02 pm

Michael Canavan wrote: ↑Thu Feb 03, 2022 3:02 pm So what is the solution then? I've been looking into NAS systems lately, and I mostly plan to have it hooked up directly via 10GbE or TB4 to the Mac here. Does a direct non WiFi based network storage solution also run into this issue or can I set up the NAS to read/write via TB etc. like a DAS?

Oh and obviously the solution isn't pretty but downloading then overwriting the copy on the NAS is a way to get the files in and out of the NAS I guess.

I'm guessing but I suspect that you're good with a direct connection either way as long as the NAS is fast enough (4 or more HDDs RAID 0 or SSDs). Apple used to advertise in 2018 that you can harness multiple Macs with a T2 and 10GB Ethernet to make a supercomputer. You don't see that since the MP 7.1 in 2019 but you can still do it. WiFi, even 5G, isn't fast enough (someday?) and Apple says it doesn't work over 1GBE — I've always figured that speed is the issue.

I think the big question isn't speed, 10GbE should translate to over 1000MB/s so it's faster than most 2.5" SSDs, but if the NAS brings in some latency off the firing line that renders it useless for actually using it to host recordings and sampler files for real time operation. It's kind of going against the whole NAS thing, but the next generation Qnap coming out soon for instance is TB4, and has two M.2 slots that can be used for storage or for cache, as well as four 3.5" bays.

That's the area of question, that NAS is mostly used for Mp3 playback, photos etc. other non real time things where initial latency isn't an issue. It's very possible it has a high initial latency before firing off at over 1000MB/s. I'm probably going to risk it. worst case scenario I only use it for storage and download things to a drive in an external enclosure that would inevitably be faster. Now that TB4 version has to come out at some time for me to try it!

Michael Canavan wrote: ↑Wed Mar 02, 2022 3:48 pm …
Now that TB4 version has to come out at some time for me to try it!

No reason not to.

E = mc2 is about a mile away from me doing near light speed wireless networking to SCSI over microwave. Down side is that one needs the defense budget of a small country to play (in case anyone wonders who the customers are). Ok, major overkill but still…

This seems ironic given the networked AVB interfaces. Those also won't update over a network either, they require local isolated direct patching to run updates.