@Kai said:

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.

@Macker said:

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. 

@Ashermusic said:

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... 

Jay, no worries about your ID mixup.

I'm stuck with Logic because of the very large subsystem I've designed, developed and been using for many years  in Logic's Environment to give me Orchestral Intonation (OI). I designed version 1 of this subsystem 20 years ago in EMagic's Logic Audio Platinum 3.5, and ran it via IAC with Reason as my sound module containing orchestral instrument samples I bought on CDs. Today I have VEPro doing the job Reason did back then.

If I'm to share my OI subsystem with other Logic users, but Apple's development of Logic thwarts that plan, it may be that my only option then would be to become an indie Apple Developer and write an app to do OI - but that's unlikely to happen. Thus if Logic devlopment continues to move away from conditions that suit my OI subsystem, I'll just continue to use OI for myself in a suitable old version of Logic for as long as possible. No doubt someone else will put OI where it belongs - in the hands of composers.

You know the roller-coaster experience of working with Apple products, so I'll say no more.

All the best Jay.

Interesting, Dewdman , I didn’t remember that!

I think you are correct though in your guess that their are so few developers who have bothered to create AU 3 versions that Logic’s utility with them, or shortcomings  hasn’t gotten any attention. As we’ve discussed, it isn’t something I care a lot about, although it would be nice to use if I it worked reasonably effortlessly, but when I see the lengths you go to to make it work, I am not willing to go there.

Macker , what a nice fellow you are, thanks. 

Logic is my DAW, period. I have thousands of hours working with it and I can make it serve any musical composition or production task I do quickly and well. VE Pro has been a good partner for it  the only way I would even think about using another is if a client said to me, “Jay, I have $50,000 worth of work for you but you need to use (fill in any DAW) to do it.”

@Ashermusic said:

 but when I see the lengths you go to to make it work, I am not willing to go there.

Well you might be confusing it with the old Vepro6 multiport macros.  None of that is necessary with VePro7 and AU3..that's why I endorse it...IF you are wanting multi midi ports to VePro.  I already know you prefer not to work that way in any case.

Using the AU3 version of Vepro7 plugin is pretty painless, it works just like any other multi-timbral instrument in LogicPro...no special environment cabling is needed or really anything..  BUT...  you do have to be careful about a a couple of things and that might be where some people get frightened or in trouble.  its not really about big hoops you have to jump through, but about a couple of traps to make sure to avoid.

1. Don't use more than 127 midi channels per VePro Instance due to limitation which hopefully some day Apple will fix.  (you can do more than 127 if you want to get more complicated jumping through environment hoops)
   
   
2. Don't use AU3 if you have a plugin that requires transport sync inside the plugin hosted in VePro7 of any kind, its currently not working.  In that case just use AU2.  (I am unable to test v10.7 to see if they fixed that but I doubt it and the problem might be VSL's fault we don't really know)
   
   
3. When creating the multi-timbral tracks in LogicPro, the typical approach is to create the first track, set its midi channel to channel 1 instead of ALL, then use CONTROL-RETURN, to add more tracks on next midi channel etc.  That is the normal LogicPro multi-timbral procedure for creating new multi-timbral tracks into a single instrument plugin.
   
   its the same with AU3, but the one little tricky thing is when you get to channel 16, you can't use CTRL-RETURN and have the right thing happen.  LogicPro needs to be improved in that regard also.  Its not that hard, you just select the channel 16 track, change it to port 2, channel 1, then go on hitting CTRL-RETURN some more to create all the port 2 tracks, etc..  Its really not a big deal once you get the hang of it.

I have found AU3 in vepro7 works totally fine and awesome actually...with the exception of being limited to the 127 midi channels and not having transport sync.  Couple other things too, right now if you save patches in LogicPro, it doesn't always save all the AU3 info, but maybe they fixed that in 10.7 when they added the multi input ports.

Anyway, I totally get your POV about using one VePro instance per source track..."like a score", that approach certainly works fine for a lot of people and I think both approaches have their time and place, but just saying, AU3 basically works fine if you avoid the traps I mentioned above.

Tricky environment cabling...well that can lead to all kinds of sorrow...so...no comment there...