fastfourier

The script ignores a lot of stuff in the chunk headers, which is probably useful type or addressing info - so this is good info, thanks. Hopefully that means we're on the right track, or at least somewhere close to it! Any contributions welcome of course. I'm not sure how much attention I can give to this project going forward, but I'm happy to add anyone to the gitlab so they can update it.

Yeah there's a lot of different stuff in there. The kind of mishmash you'd expect from the format being around for so long. Most of it is probably straight object serialization, markers and probably some other stuff (notes maybe) is in .rtf format, the "drummer" feature uses binary plist (bplist00). etc etc. I think my next step would be to enhance that script to pull certain chunks of interest and be able to diff those individually. Dealing with the whole file at once is a pain, there are a lot of moving parts/variable length fields and stuff.

Duh. OK yeah. have to set the repo to public. Try again folks, sorry about that

Um... yeah! that's it! I escaped with the valuable ProjectData information just before the laptop melted from the volcano heat! It was quite a bit less exciting than that, I can promise you. Anyway, I've linked my gitlab on the subject. I'd post it directly here but I'll hopefully be updating the info in the future as time permits. My goal was to just parse the overall format of the file into component "chunks" and that seems to work pretty well. There's a python script to demo this that dumps out a listing of chunks in the ProjectData. Hopefully this also works on more modern versions of Logic than mine. There is some brief investigation into the actual content of various chunks, and it doesn't look too bad in terms of difficulty. Meaning that when you change one thing in the Logic project and save, it results in only one (or a few) changes in the project file. It doesn't seem like the data is obfuscated/packed in any way. https://gitlab.com/fastfourier666/cigol

I had a few hours alone in the middle of nowhere with no internet and managed to figure out how the whole ProjectData file is put together. As for investigating the actual content of the many data "chunks" that's quite the mission, there are over 450 of them in a "new project" with a single audio track and no regions. I did get some meaningful results from some experiments but ran out of time as I got rescued (!) I'm happy to post a link to what I got but just let me know David if you would rather I didn't due to legal issues. There is a commercial tool "splice" which is able to pull apart Logic projects as far as regions, tracks and plugins so the info is definitely out there. However I don't know what kind of agreement they might have with Apple.

Oh I didn't realise there was MIDI FX. I usually use this technique for outputting RTA info as MIDI, so it needs to be in the audio signal path. Bidule is much better for this anyway; I only tried to give it a shot in Reaktor because the poster above was using it.

Oh, you can load R6 in place of R5, and then load the .ens file (in the project folder)

It works in R6, and you can change the channel number of the fader input depending on which slot the plugin of interest is. 2=instrument slot, 3 and up=inserts. Never had issues with timing though.

You can. Kind of. If it's continuous controller type data, you can sneak it out as automation/fader without too much trouble. Notes would be a little harder to encode/decode. Here is an example with a Reaktor LFO controlling the ES1 cutoff on another channel via MIDI CC. After loading the .ens file into Reaktor, turn off settings -> sync to external clock and click the "START" button on the panel to get it going. Maybe someone clever can figure out how to make it do a "loadbang", but I am not that person. https://www.dropbox.com/s/76ri2uaxy1yndq9/automazeontest.zip?dl=0

See! That's why you should never update! It actually breaks your computer! /s Good luck with the repair!

For MIDI, the RTPMIDI/AppleMIDI works pretty well (in Audio MIDI Setup) The only pain is that sessions don't automatically recover/reconnect, but I guess you can get aroudn that with some AppleScript. Dante is great. It's one of the handful of Ethernet-based protocols used in live sound and broadcast, so you know it's got a good rep for being solid

On a technical level it's not really the best solution for transporting audio anyway - you'd be much better off buying a couple of Dante licenses if you want it to "just work" On a local network with plenty of bandwidth though, it works pretty well. What would be really nice is something that can receive/send streams and present them as virtual audio I/O devices.

I'm assuming that 0.95 is a version just from the look of it, and the fact that it gets sent at the beginning of proceedings. I was wrong on my previous post about what constitutes a "connected" status in aunetsend - the relationship between the data and the status is: Listening - waiting for a TCP connection Connecting - TCP connection has established, "ausend 0.95" sent, waiting for "aunetrecv" reply from aunetreceive Connected - "aunetrecv" has been received, now streaming audio If the aunetsend stays at "listening" then nothing is getting through from aunetreceive. There must be something stopping the connection being made. Try this: on the aunetreceive machine, go into Terminal and type nc xxx.xxx.xxx.xxx 52800 where the xs are the IP address of the machine running aunetsend. That should cause the aunetsend to change status to "Connecting". If it stays at "Listening", then there must be a firewall or something running. I didn't realise that you were going to try installing the .component file as a plugin! Interesting that it changes something. The coreaudio.component file is basically *all* of CoreAudio. Plugins, default sounds, all that stuff. I was suggesting taking that file and copying it to the same location on one of the machines that didn't work, thinking that there was a version mismatch between the protocols. I do like a good investigation! good luck

Good luck with the experiments! Maybe that is a "Sierra thing". Some additional info - once aunetsend is listening, you can check the protocol version on the local machine by doing nc localhost 52800 in Terminal.

No worries! When aunetreceive connects, aunetsend returns a version number. This is a different version number from what you see in the plugin manager in Logic - I'm guessing this is the protocol version rather than the plugin version. I'm guessing that aunetreceive will only accept audio aunetsend if its protocol version is equal or greater. If you want to look into this further, you can download Wireshark and use tcp.port==52800 as a display filter. The protocol version is the very first piece of data sent once aunetreceive connects. Unfortunately the "listening/connected" status only shows that a TCP connection has been established. It doesn't say anything about the state of the link between the two machines. I don't know if there's any chance of updating the coreaudio component (/System/Library/Components) on the old machine? If you really don't want to reinstall, you could try copying that over from the new machine to the old one. WARNING. This is a silly hack and may well break the OS (at least audio-wise) so make a backup first!