I really hope the software I depend on will continue working on Mojave for still many, many years, before I have to switch to the catastrophe that are the later OS releasesā¦
(Unfortunately, I updated my iPad and iPhone, sighā¦)
Paolo
194,096 users have contributed to 42,911 threads and 257,915 posts.
In the past 24 hours, we have 6 new thread(s), 21 new post(s) and 80 new user(s).
Its part of why I am moving on to Digital Performer. Too many tricky hassles with LogicPro and I don't want to move to Big Sur or Monterey for at least a couple more years...
That is some weird problems you are having Macker, I have not much I can add as I am not using Big Sur nor LogicPro. I can only say that in the past there have been some weird problems associated with older versions of LogicPro project files being opened in newer versions of Logic Pro. But the fact that you said your old projects opened in LogicPro 10.4.8 wrongly...just by virtue of 10.7.1 being installed on your system is REALLY weird... anything is possible with Apple though.. I suspect it has something to do with opening 10.4.8 projects in LogicPro 10.4.8 on Big Sur...more so then the fact that 10.7.1 is installed...but anything is possible really..
I was rather hoping that Apple would have made AU3 more solid with newer versions of LogicPro on newer versions of MacOS, but from the sounds of it, AU3 has become more buggy, perhaps related to the input port changes they did...who knows.
But its disheartening to find out that the environment is becoming less stable also...
Anyway, for me this is just one more news story about LogicPro that leads me away to DP or Cubase from here forward.
In Big Sur, not only does Logic 10.7.1 not work on half the ports when used with my VEPro AU3 Template, but it also visibly corrupts my previously tested and working constructions in the Environment in Logic projects built with 10.4.8. Moreover, this Environment corruption occurs even after a previously tested and working Logic 10.4.8 project file has been opened in Logic 10.7.1 but never saved in 10.7.1, then subsequently opened in Logic 10.4.8. Even worse, if I'm not badly mistaken, the corruption also happens in 10.4.8 projects opened specifically in 10.4.8 but never having been opened in 10.7.1 - while 10.7.1 is merely there lurking in the Applications folder.
Hence I'm now treating Logic 10.7.1 as if it's malware.
Furthermore, if you use a VEPro AU2 multiport Logic template, I strongly suggest you treat it as potentially at risk from Logic 10.7.1.
I've done some radical "disinfecting" by deleting all versions of the Logic app later than 10.4.8 from my Big Sur boot volume, and by using Time Machine to restore all my Logic projects from backups done before I updated Logic 10.4.8 and created my Big Sur boot volume. And that means I've effectively lost many, many hours of work since mid-July on developing older projects and creating new ones.
I'll spare you my current thoughts and feelings about the 'developers' working on Logic at Apple Park in Cupertino.
This sounds just horrible, sorry to hear you are having such trouble.. Can you elaborate a bit what exactly got corrupted in the environment and does not work anymore. I am using the environment extensively and fortunately did not experience problems in 10.7.1./Big Sur so far. However, I had plenty of similar problems with previous versions of Logic where (for years) things just would not work anymore after an update.
It unfortunately seems the environment is some legacy part of their code that hasn't really been maintained for far more than a decade and that they just carry around. Yet, every once in a while they break parts of it when they port it to a new framework, since no-one really understands anymore how the code works in detail.
It unfortunately seems the environment is some legacy part of their code that hasn't really been maintained for far more than a decade and that they just carry around. Yet, every once in a while they break parts of it when they port it to a new framework, since no-one really understands anymore how the code works in detail.
That has been my observation also. The original founders/coders of Emagic still work for apple, but it is unlikely at this point they personally do much coding anymore... and like you said..the Environment code is really old. Actually I suspect it was done in assembly language or something of this nature. I also suspect there is a lot of 8bit integer stuff coded into the environment that would be very time consuming and/or difficult to go back and update to modern capabilities. In my mind it's a miracle that the environment even still works at all.
My experience with AU3 in LogicPro up until 10.6, has been that you can't have more than 127 instrument strip objects referring to one actual instrument object in the environment. This is how multi-timbral scenarios are handled in LogicPro...each channel (or port/channel in the case of AU3) creates an additional instrument strip object. For example if the instrument holding VePro.AU3 is "Inst1", then each time you add a new track with new channel, an additional channel strip is created in the environment, referring to that Inst1 object.
However, you can only create 127 of them. If you create more then 127 of them, then literally the entire LogicPro GUI will blow up, the GUI will have blank spaces...the channel strips in the environment will all go blank, Not only is 128+ channels not supported, but merely trying to add that 128th channel will cause the environment to go wonky. This is true in older versions of LogicPro and perhaps latest version too.
I believe that is some kind of 8bit integer limitation somewhere in the environment code.
Lots of things in LogicPro are limited to values 0-127 even though they should not be. For example, in the articulation set editor, if you try to use PitchBend as an output switch..you're limited to values 0-127.
The AU2 environment macro approach for using VSL with multi-ports has always been running into bugs in LogicPro's environment and did not work properly ever in the templates that were provided by VSL...due to bugs in the Transformer object of the environment. Specifically this is related to NoteOn/NoteOff confusion in the way transformer handles notes coming from a region vs coming from live input. There are work arounds, but the VSL templates did not have those work arounds and never worked right.
Paolo, previously, for as long as possible I too held onto versions of MacOS and Logic that worked just fine. But more recently I've needed to know if the latest Logic and macOS would help, hinder or not affect my Situater subsystem, given that I was getting it close to release. But now I'm thinking it could turn out that I just keep Situater for myself. (In which case I'd lobby the Dorico team to do it for everyone else.)
I think it was Logic 10.3 or thereabouts that the Transformer's 14-bit arithmetic was broken; it could then do only modulo 256 arithmetic (i.e. 8-bit). I sent a new bug report about it to Apple for every new release of Logic in which the Transformer was still not fixed. Meanwhile I'd redesigned the relevant parts of Situater to use the Transformer in its broken state, although this meant Situater could no longer use 53 pitch classes per octave. But lo and behold! Ironically, in Logic 10.7 the Transformer can once again do 14-bit arithmetic!
I'd say version 9 was the the most recent good Logic. And Snow Leopard the most recent good Mac OS.
It seems Apple's constantly replenished army of young noob proggies and coders just can't help rushing to demonstrate the truth of the "Peter Principle" (i.e. that people rise to the level of their incompetence) - the result being what in Finland they call "uusavuton" ("the new helpless"). Also, perhaps Apple management are busy proving the truth of one of the corollaries of C. Northcote Parkinson's Law, under the chapter "Plans and Plants", in which Parkinson points out many historical examples of the perfectly purpose-built new building being a portent of the organisation's terminal decline and ultimate demise! Not knowing anyone working at Apple and not knowing a thing about how Apple employees actually work, these are of course merely the images I conjure to try to make sense of the often baffling outcomes of Logic and MacOS updates, Lol.
Kai, the worst example of corruption I saw in the Environment was a small, simple numerical fader in use as a buffer, originally with one in and one out, changed radically into an absurdly tall thing, almost the height of the screen, and with dozens and dozens of output terminals, several of which had mysterious off-page connections but the context menu didn't offer the option of selecting the destination object of any selected output cable.
With that kind of horror happening, I dread to think what else might have changed but not be visible. It's simply not worth the risk of trying to fix it up in a multi-page Environment subsystem as big and complex as my Situater.
Just in case the problem is that my Situater build is now too old - in the sense that it has already been through too many major updates of Logic - I might have to do a total clean rebuild from scratch, to see if that gets treated any better by the latest Logic.
Dewdman, that's an interesting observation with the 8bit limitation. As you write, underneath the fancy surface everything in Logic is still built on the old environment code (even in the most recent version). They try to hide it as much as possible, but they simply need it. I guess this is (unfortunately) the only reason why the environment and all its nice Midi capabilities still exist. But it is indeed basically a miracle that all this still works (to some extent), taking into account what changes the architecture went through since the code was created (PPC, Intel, Apple silicon). The old artwork of some faders from the 90s alone is just incredible in a fancy Apple product in the 2020s š. Anyway I really hope they give it a major overhaul at some point instead of removing the environment completely.
Macker, this sounds even worse than what I had feared. I know exactly how you feel, after having spent a lot of time to create a fancy environment that works and that your current workflow depends on, just to have to abandon it because of something like this. However, if the bug is so obvious, this should make it easier to communicate it in a bug report. The Apple team is incredibly slow (and one never gets any feedback), but hopefully they will eventually fix it this way.
for sure LogicPro is still based on internal "objects", which are represented in the environment, such as channel strip objects, etc. And that underlying engine has not been rebuilt from scratch, Apple came in and put more of a WYSIWYG gui wrapper around it, making it incredibly easier for the average user. Before that, Logic was a bit of a turn off for many people because you had to understand about stringing objects together before you could record a single note of music. With Apple's GUI, they made more like typical DAW's, just add a track, select it and start playing your midi keyboard... but under the covers, LogicPro is still stringing together objects in the environment to accomplish all that using the same underlying object engine.
But anyway the environment is mainly about how midi is routed. The channel strip objects do handle audio obviously, but all the environment does is bring those channel strips into existence. Audio channels get their audio input from somewhere else outside the environment...and send their audio someplace outside the environment..the environment doesn't have that much to do with it. In the environment though, they added all the midi stuff, transformers and so forth..which became kind of a cool thing that other DAW's didn't and don't have. For that reason, its still around and I don't personally think it will go away. (though it is interesting that the environment did not make it into MainStage. MainStage instead includes a set of typical filters that satisfy most people...without the extreme flexibility of LogicPro's environment. It quite possibly is still using the same environment underpinnings though....just no actual environment GUI provided in MainStage).
But anyway, midi was an 8 bit protocol for the most part with with tricky things at times about sending multiple bytes as separate "midi messages" that can be reconstructed into larger data values, but each midi message was 8 bits essentially, and in programming back then it was common to keep integer sizes as small as possible. if you only needed 8 bits, then you would program the thing to use 8 bits, to conserve memory and reduce any processing to absolute minimal. So its not at all surprising to me that Emagic would have "optimized" the environment in many ways to pass 8 bit numbers around and do fancy bit math on it to extract various things out of the 8 bit bytes, etc. That would have been considered an "optimization" back in the day.
so anyway, my opinion, the guts of the environment in terms of how midi is routed around..is the part that is probably stuck a bit in 8 bit. And quite possibly it was even written in assembly rather then using a compiled language like C/C++ honestly. There is all kinds of weirdness that we don't know about. 8 bit midi messages are already packing just about all the info they can pack per event. So then, LogicPro has added things like midi port and articulationID as additional attributes of events... and they do somehow make it all the way to the plugins in the instrument channel...but...we can't see those attributes at all in the environment...all the transformers and everything are completely blind to it. So..obviously there is something inside LogicPro that represents midi events with more then 8 bits...but the environment still has old 8bit cob webs all over the place....and basically it does not surprise me at all if occasionally something will cause it to throw fits...and it would probably be very difficult for a current engineer at Apple to go figure it out...and they are probably, and rightly, scared of breaking it! So they don't want to muck with it too much unless they really have to.
Fake-news-numpty alert!
I wish internet social platforms were more like real life. Then I'd say something like:-
"you're clearly not a design engineer, nor will you ever be one. And as one who very obviously does not have an engineering backround your pretence at speaking authoritatively on engineering matters would be laughable if it wasn't for the fact that others may be fooled and led astray. Go away and play your make-pretend games somewhere else, you numpty."
But since this is a social platform, and saying such things is generally frowned upon, I'd better not say it to anyone here. Lol.
Dewdman, I fully agree with what you wrote. In particular the implementation of "extended Midi functionality" like Articulation IDs and their relation to ordinary Midi data is just weird and completely incomprehensible in Logic. Even after nearly a decade it does not work at all to simply record Articulation IDs from a Midi keyboard the way they had intended it using Articulation Sets. There are commercial tools that do nothing else than to fix the mess that Apple left and somehow make this work. It took me years to accidentally figure out how to get this to work, and it was only possible with some odd transformations in the environment, so that all of a sudden Logic would recognize Midi events it would otherwise just filter out.
Well to be fair, I haven't had the kinds of problems you are reporting now. The articulation set has input switches and if you configure it properly you should be able to record keyswitch changes that are converted during record into midi events with articulationID encoded in them.
My only point above was that articulationID is not sitting within the typical 8 bits mentioned, and the environment transformer is unable to see or set the articulationID.
Its not possible to use the environment to detect nor encode articulationID in any midi events, directly. I would be curious to hear more about the "odd transformations" you used, related to articulationID??
You said that Logic was filtering out midi events, but that was most likely because you had some keyswitches defined in the input section of the articulation set. And by design those will be converted into articulationID (and yes the keyswitch itself will be filtered out in the process). You can turn off that behavior several different ways.
The other thing that can eat midi events in LogicPro and sometimes confuse people is if and when you have any kind of control surface enabled....then any midi events that are defined within the Control Surface editor will be eaten by the control surface engine and won't make it into your regions as you record. I doubt that is what was happening to you before...but just mentioning it as the other way LogicPro might cause midi events to mysteriously be filtered out.
UPDATE: In Logic 10.7.2 with VEPro 7.0.1056, using the same AU3 test rig that I sent a copy of to VSL Support with my first report about LP10.7.1, thus far I've found the following:-
ā¢ All MIDI Note Offs are still 'postponed' until Logic transport is stopped, when playing back from a MIDI region, in half of the 48 VEPro ports. Same as in 10.7.1. No word from Apple about any fixes to AU3 Port Out assignments, routing or handling etc..
ā¢ The visible corruption that happened in my large-scale Logic Environment subsystem in 10.7.1 does not appear in 10.7.2. But no word from Apple about any fixes in the Environment.
Apple's Release Notes for LP10.7.2 show about 75 fixes, none of which relate to my particular problems.
Thus my copy of Logic Pro 10.7.2 joins its predecessor in quarantine.
Ahh, fond memories of Apple's shift to Intel, and their introduction of Logic Pro X. Lol.
Anyone fancy starting a class action for fraud in Apple's use of the word "Pro" in Logic Pro? Lolol
1. Logic has never supported multiple MIDI ports.
2. Apple doesn't fully or officially support AU 3.
3. VE Pro AU 3 is beta software.
So no, I will not be joining a class action against Apple.
Good luck with Digital Performer, Macker. I predict you will find that you are out of the frying pan and into the fire, but maybe not.
Au contraire, Ashermusic. As VSL informed us, VEPro7 (AU3 Beta) was the world's first plugin in which Apple's new AU3 support for multiple MIDI-Out ports was implemented; even though it's still Beta and now in a badly broken state, unlike in LPX 10.4.8.
If you have reliable information about the status of AU3 in Apple, please do share it with us, citing your source(s).
My class action remark was just a quip - as signified by a customary quip-signifier:- "Lolol".
I've no idea why you mentioned DP. It's nothing to do with me and I've nothing to do with it; nor have I ever had even the slightest intention of becoming involved with it.
Au contraire, Ashermusic. As VSL informed us, VEPro7 (AU3 Beta) was the world's first plugin in which Apple's new AU3 support for multiple MIDI-Out ports was implemented; even though it's still Beta and now in a badly broken state, unlike in LPX 10.4.8.
If you have reliable information about the status of AU3 in Apple, please do share it with us, citing your source(s).
My class action remark was just a quip - as signified by a customary quip-signifier:- "Lolol".
I've no idea why you mentioned DP. It's nothing to do with me and I've nothing to do with it; nor have I ever had even the slightest intention of becoming involved with it.
Beta is beta is beta. I have been doing this since 1990 and I am always surprised when anything beta worksš
I have no insider info from Apple about this and frankly couldn't care less about it. My view has always been that if I could not accomplish what I needed too with 16 MIDI channels, I would not see myself as very skillful.
Sorry, it was someone else who mentioned moving to DP.
I donāt think Apple ever referred to AU3 comparability as being ābetaā. In fact I think it would go completely against Appleās philosophy to have a ābeta featureā inside a fully released product. Iām not sure I can recall apple ever releasing ANYTHING in declared beta form actually the more I think about it.
AU3 support in logicpro was actually documented formally as a feature of logicpro like a year before vsl actually attempted to use it in vepro7. I'm afraid I can't cite a reference for that, but I remember finding it once in the past as a release note in one fo the past versions of LogicPro.
Vsl most definitely did declare vepro7ās AU3 feature to be ābetaā according to them; because they didnāt feel, and rightly so; that logicpro really had AU3 support completely working. Mainly they referred specifically to the fact that logicpro was limited to 127 midi channels and unable to support 768 midi channels on 48 ports that vepro can actually do. But apple has not ever referred to their own AU3 support as ābetaā, not that I have ever seen.
For the most part I have found logicpro AU3 mode to work fine with a few little hiccups which can be avoided and worked around if you desire to do so; just like many other so called LogicPro features. I have found itās AU3 support to actually be far more reliable and predictable then the environment itself.
Asher you may have read a post from me about switching to DP, I have been in the process of doing that since DP11 came out with articulation maps; and so far I am really really liking DP11 a lot!
It doesnāt mean I have given up entirely on logicpro, they both have certain pros and cons, but each time apple releases new macos and new logic they do seem to bring in many bugs in logicpro, from what I have seen a lot of people are running older versions of logicpro either because the newer versions broke something or because they canāt run the newer version of macos that is required by each new version of logicpro. its a very slippery situation that is hard to keep up with.
On top of that you have some critical bugs related to PDC, side chaining, even proper PDC and automation, etc.. that have been lurking around unfixed in LogicPro for a very long time. Also LogicPro has continued to be way behind the curve on certain things such as nested track folders, track selection features and other features that people with large templates seem to run to other products like DP and Cubase for.
As much as I enjoy logicproās music writing toolsets, scripter, even the environment; I find this version-chasing stuff with LogicPro all a bit Kaotic and unstable each year. Itās remarkable software for $199 and never charged for an update; but honestly there is also a bit of madness and time-drain happening with LogicPro. DP, cubase, reaper and other daws are FAR more stable and reliable in comparison; particularly with regards to the fact that you can usually run them on significantly older versions of MacOS, which many people choose to do for reasons of stability.. (Knock on wood).
Though none of them are without their own problems, no doubt about it. It always comes down to personal preference and as far as Iām concerned every single daw out there has a few cool things I prefer over the others in some way. Well except maybe for reaper, I have no love for that one! ;-)
Nice to hear from you I havenāt seen you around in quite a while
I didnāt say Apple. calls it a beta, VSL does. The plug-in is named AU Beta when you access it in Logic Pro, as you acknowledged.
My memory could be letting me down but I donāt remember Apple ever saying that AU 3 was fully implemented and supported.
As for DP, funny, but in recent years a number of people hired me to help them migrate to Logic because they were unhappy with DP, but I donāt do DAW wars. They all have their pros and cons. But most users who have used multiple ones concede that while they may prefer Cubase or DP, Logic is more efficient in running software instruments and fx but of course VE Pro helps all of them with that. And Cubase, on the Mac at least, is less stable than Logic, according to the Cubase Mac people I talk to. They use Cubase in spite of that, not because of that.
Again, though, I donāt care which DAW people prefer.
My memory could be letting me down but I donāt remember Apple ever saying that AU 3 was fully implemented and supported.
Check the release notes for 10.3.1
https://support.apple.com/en-us/HT208471
The thing is, prior to VSL releasing VePro7, I'm not aware of a single AU3 plugin that was distributed by anyone else (on MacOS)...regardless of the fact that LogicPro was apparently ready for it. So we just didn't hear much about it.
In fact, my opinion would be that LogicPro inherited AU3 support the minute AU3 was added to CoreAudio, which was probably well before 10.3.1.
v10.3.1 just bumped up support in LogicPro to actually enable the use of multiple midi ports in AU3 plugins.
As for DP, funny, but in recent years a number of people hired me to help them migrate to Logic because they were unhappy with DP, but I donāt do DAW wars.
people are fickle and switch boats for a variety of reasons and frustrations in both directions. All the DAW's have pros and cons, LogicPro and DP both are no exception.
I also left DP for LogicPro at some point in the past, but now I'm heading back as MOTU has fixed a lot that I was frustrated about in the past and DP still offers some features no other DAW does, which I really like, such as chunks.. (shrug).
They are all decent choices...