Jeremy

Hi, Peter Elsea kindly sent me the most recent source code for the Lobjects, I've compiled them for macOS x86_64 and arm64 and zipped up the results 

. If anyone wants to take them for a spin, that would be helpful. The helpfiles and canonical versions can be found 

Please provide any feedback here (even, "hey, they just work" is useful). I'll continue to work with Peter to see if we can create a more official package for these venerable, but important contributions to Max.

2022-05-05: updates to linc, lbuildset and lshiftr (

2022-08-30: revert lshiftr change after consultation with Peter Elsea (

Hi, Peter Elsea kindly sent me the most recent source code for the Lobjects, I've compiled them for macOS x86_64 and arm64 and zipped up the results here. If anyone wants to take them for a spin, that would be helpful. The helpfiles and canonical versions can be found here.

UPDATE LOG
2022-05-02: initial post (builds)
2022-05-05: updates to linc, lbuildset and lshiftr (builds)
2022-08-30: revert lshiftr change after consultation with Peter Elsea (builds)

Hi, Peter Elsea kindly sent me the most recent source code for the Lobjects, I've compiled them for macOS x86_64 and arm64 and zipped up the

peter-elsea's-lobjects-macos-universal-x86_64-and-arm64

Thanks for posting them. Most work, a couple don't on my system. mac 11.6.5 max 8.3 

Is Lbuldset the same as Lbuildset? Unzips as Lbuldset for me. Does not instantiate.

Linc just displays 2147483647 or 2147483648.

Lshiftr moves something like 100,110,111 rather than 100,010,001

Thanks for posting them. Most work, a couple don't on my system.   mac 11.6.5 max 8.3  

Is Lbuldset the same as Lbuildset? Unzips as Lbuldset for me. Does not instantiate.

Linc just displays 2147483647 or 2147483648.


Lshiftr moves something like 100,110,111 rather than 100,010,001

* lbuildset is back and spelled correctly

* lshiftr was totally busted, I can't believe it ever worked. But now it does. It's a very weird object, though, since it operates on both incoming lists (which are not cached) and a cached list. An int in the left inlet causes the cached list to be output, an int in the right inlet sets the step size for incoming lists in the left inlet. Strange design, but I won't change it. The shifting should work as expected now.

* lbuildset is back and spelled correctly
* linc should be working properly now
* lshiftr was totally busted, I can't believe it ever worked. But now it does. It's a very weird object, though, since it operates on both incoming lists (which are not cached) and a cached list. An int in the left inlet causes the cached list to be output, an int in the right inlet sets the step size for incoming lists in the left inlet. Strange design, but I won't change it. The shifting should work as expected now.

Now that I think about it, I'm a little unsure about my "fix" to lshiftr. I suspect that it's supposed to work like C-style bit shifting with sign extension (in which 1000 would indeed shift right as 1100, 1110, 1111), but I've asked Peter for clarification on that point. I don't know what use that sort of shifting would have in Max, but that's generally the wrong question to ask...

There are plenty of objects which perform list rotation, in any case, if that's what you need.

After checking in with Peter Elsea, the previous behavior of lshiftr was correct: it is supposed to kinda-sorta behave like C's >> and << operators with "sign extension" (sign extension in C is limited to >> since the sign is always the MSB). If you need to rotate a list, there's 'lror', or just 'zl.rot'.

. Unless there are any additional problems, and once I get a sec, I'll put together a final release with Windows externals and get this up on the package manager.

Here are new builds. Unless there are any additional problems, and once I get a sec, I'll put together a final release with Windows externals and get this up on the package manager.

Delayed thanks for this work Jeremy! I grabbed the ones you linked to in your last post above, but I don't see them in the Package Manager, is that still in the works?

Delayed thanks for this work Jeremy!  I grabbed the ones you linked to in your last post above, but I don't see them in the Package Manager, is that still in the works?

Trojan Horse is a privately owned IT Support and 

 business formed in 2019. Today we’re proud to boast a strong team of IT engineers who thrive on rolling up their sleeves and solving your IT problems and meeting your business needs.

Trojan Horse is a privately owned IT Support and IT Services business formed in 2019. Today we’re proud to boast a strong team of IT engineers who thrive on rolling up their sleeves and solving your IT problems and meeting your business needs.

@dan, it's still a ball in the air, we'll get there!

Thanks so much Jeremy - I don't have a silicon Mac myself, but I'm trying these with an end user of one of my standalones who does have one, and he's not having success with either bit or lbyte, showing "could not load due to incorrect architecture" in the Max window when the app does not have "Open using Rosetta" checked off. Ideas?

Thanks so much Jeremy - I don't have a silicon Mac myself, but I'm trying these with an end user of one of my standalones who does have one, and he's not having success with either bit or lbyte, showing "could not load due to incorrect architecture" in the Max window when the app does not have "Open using Rosetta" checked off.  Ideas?

Looks like they are both universal, I'll need to get on my ARM machine to test, but it's more likely that you, or the user, has old versions lying around which were accidentally included/loaded in the standalone. If you want to send the standalone over I can look (or you can use lipo from the CLI to check yourself).

100% correct Jeremy - not sure how, but using lipo looks like both Bit.mxo and Byte.mxo are "i386 x86_64", with no "arm64" in sight.... Now I have to figure out why those older versions were included!

Sorry for the noise, will report back if any further difficulties. Thank you again!

Sorry for the noise, will report back if any further difficulties.  Thank you again!

Peter Elsea's Lobjects macOS universal (x86_64 and arm64)