alexharker / aharker_externals Goto Github PK

After a bit of troubleshooting this morning I figured out why some old code (in C-C-Combine) wasn't working properly. The first part of this is that sfm now reports in dB, which is more useful, but not the same as before, and not the same as what the documentation says at the moment("a value between 0 1 - 1 indicates a very flat spectrum and hence more noisy..."). I think dB is a more useful metric here, and in my patch I was doing some atodb stuff with clamping to remove INFs, but maybe having an option to revert to old behavior (or at least stating the new behavior in the documentation) would be useful.

After going to reanalyze my files with this in mind I was greeted with a console window full of descriptors~: zero length file or segment. It seems that the updated version takes the fftparams as a minimum segment length so if I send descriptors~ a message of analyze buffer 1 0. 40. with fftparams 2048 128 (@44.1k) I get the zero length file or segment error. If I change my message to analyze buffer 1. 0. 46.44 then it works properly. This makes logical sense as that is how big that segment needs to be for the fftparams to analyze a full frame, but it does break existing patches as this was not clamped previously. I don't know if the previous version just zero-padded the end of something, but it did return values.

I can easily change my local code to take this in mind, but mainly thing that there's quite a bit of this code out there in the world which will no longer work.

to reproduce:

1. click the settings
2. analyse the buffer
3. watch the results
4. opening the same patch in old public releases generates [-180. 0. inf]

----------begin_max5_patcher----------
680.3ocsUssiZCCD8Y3qHJOyh7LiuLt+JUUUYACMqBNnDyVPq18auSbfVZK6
V5dQh3nY3XOy43icdX5jxaa2G5KK9TwmKlL4goSljSMjXxw3Ikap1unopOCq
LF9d6s2UNa7uRg8ob5a2sZUn6oh95lPbQPBK.k5Dr3tM0wlPJuDvwj8oCMg7
jOCV6tzIb3wraqRK9Vcb8W6BKRisp1gyUyJPjFdAneLZtp3KGmz35jNrMLNi
xUMsUoxYRmVEWW9Sb0KycfPoa7kCodb5zggYWobrIz2WsN7W5wM.qlWH+.m2
Y8DPZ1hDXbJFzFzoQxQfSoIi04YkSIuMng0Zu2Z7rGbZmkUCyAsJGqTHaH1Y
UF1aLrkPm0xNFbfQqzCYICnIF0VY40DBDZY1Kg.KfYsTB4QQFxY.qmsJoZfx
3rFCfLpbVTazdkxqH1SnLYsxIEiMJVKfHxKq8P0HjrBJDQulAqgUrw3IopHI
rUnnPcFsnRCZYGi.oYIoach13AO58LCnQI8tBs.qATyx5Z44mzyl5XXQ6tXV
TMzkrS3UZmfm2NQ1A+CmGMpgQG3eIyzE8O76o+oJV0bnOb14oxOHxiiLFAHe
VRcEmktH8sumze0pz1ptpM8Eh6gkS37rhkg9Ec0aSsc8EgXna8ggqXjMLY.J
1DVVWEK1VKDTN2YsmxzuZSFm7HiiIun8B+fDXfbYKUdTi4Wj4+VeoWi99L2V
elT9za5N5Wh1174IzlMTN6+1V0T2mtH0gyodFPdm6O9tUtGFx+65Qe6ttEmJ
wnQcVwu5BQJR0wpTca7LLvHlKp3WacfqnNrfAdi0gdU7YTFq1t89PW+Qv4RH
Fn6Z6FBcyxg0wwv7sukcg6qOg2jyT0Ia8IYeeW2nUYuUWNN01kgt3t5rSY5P
keb5O7W0xSH
-----------end_max5_patcher-----------

Hi Alex,
I'm trying to build your externals in XCode and I get this:
AH_VectorOps.h:387
Constant expression evaluates to 9223372036854775808 which cannot be narrowed to type 'long long'.
No big deal for now as I don't need the descriptors object, but I wanted to let you know. This happens on Mac OSX 10.13.6, XCode 9.4.1, building against the Max SDK 7.3.3.
Take care,
andrea

when setting ibufconcatenate~ to message mode by setting the second argument to 1, it does not correctly output the list of data (stat sample/end sample/sample rate) when an int query is input. It only outputs [0 0 0.] regardless of the query.

100% reproducable crash (on my system, details below) when double-clicking an "empty" entrymatcher. This happens if the object is named or unnamed, has size/columns or not.

Steps to reproduce:
instantiate entrymatcher, double-click it

This is with version "1.1" created on 19/07/2019 according to Finder.

Crash report:
crash1.zip

A suggested improvement for entrymatcher~ would be the ability to query from a starting column and for a given range to making for tidier messaging if you're just trying to find the nearest equal match across a normalized/standardized range of values.

So something like column1 20 % 1. [$1 $2 $3 etc...] to query starting on column one, for two columns, followed by the list of values for the query.

Instead of having column1 % 1. $1 column2 % 1. $2 column3 % 1. $3, etc...

Or an even fancier-pants version would be to have matchers messages be "sticky" or @attributes-y where you can specify the type of query you want (e.g. column1 20 % 1. ) and then just send the values to be queried.

Steps to reproduce after installing Max 8 and Xcode:

1. Clone https://github.com/AlexHarker/AHarker_Externals.git
2. Download Max 8 SDK Version 8.0.3 https://cycling74.com/downloads/sdk and unzip. Copy the contents of source/ into AHarker_Externals/AH_Max_SDK
3. Open and edit Config_AHarker_Externals.xcconfig and change MACOSX_DEPLOYMENT_TARGET = 11.3 and ARCHS = x86_64 and SKIP_INSTALL = NO and DSTROOT = $(SRCROOT)/../../build
4. Open AH Externals.xcodeproj and Product>Build.
5. You will see two errors in AH_VectorOps.h saying Constant expression evaluates to 9223372036854775808 which cannot be narrowed to type 'long long'. Click on the "Fix" button twice which will change line 387 to static const vSInt64 max_negative = {static_cast<long long>(0x8000000000000000), static_cast<long long>(0x8000000000000000)};
6. Product>Clean Build Folder and Product>Build again.
7. Open the AHarker_Externals/build folder and verify that the externals are present.
8. Open Max and create a new patcher. Save the patcher in AHarker_Externals/build.
9. Check that some externals work: create a [ macaddress ] object, patch it to [ print ] and bang it.
10. Check that other externals crash: create a [ timeconvolve~ ] and Max crashes with MacOS reporting the error at the bottom of this post. I tested across a few different categories, here are a list of crashing externals:

• valconvert
• timeconvolve~
• partconvolve~
• schedulemessage
• randfloats
• randomvals~
• meandev
• timemap
• entrymatcher

And here are some working externals:

• macaddress
• recursivefolder
• depack
• denormkiller~
• getthread
• threadfilter

I was able to get [ macaddress ] to crash by adding a property double param; to typedef struct macaddress and then adding the line x->param = 1; inside macaddress_new(). Interestingly, if param is an int type (long, int etc) then it does not crash.

Process:               Max [2474]
Path:                  /Applications/Max.app/Contents/MacOS/Max
Identifier:            com.cycling74.Max
Version:               8.1.11 [17de540] (8.1.11)
Code Type:             X86-64 (Translated)
Parent Process:        ??? [1]
Responsible:           Max [2474]
User ID:               501

Date/Time:             2021-06-27 13:34:30.817 -0700
OS Version:            macOS 11.3 (20E232)
Report Version:        12
Anonymous UUID:        F597B9C8-DAE5-21C0-D355-0324D82A40CB

Sleep/Wake UUID:       A05788FB-3E5C-4DDA-A540-3809709E1573

Time Awake Since Boot: 2500000 seconds
Time Since Wake:       11000 seconds

System Integrity Protection: enabled

Crashed Thread:        0  CrBrowserMain  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes:       0x0000000000000001, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Illegal instruction: 4
Termination Reason:    Namespace SIGNAL, Code 0x4
Terminating Process:   exc handler [2474]

Thread 0 Crashed:: CrBrowserMain  Dispatch queue: com.apple.main-thread
0   partconvolve-                 	0x0000000162553fe1 main + 1185 (partconvolve~.cpp:188)
1   com.cycling74.Max             	0x0000000102cff06e external_bundleload + 1036
2   com.cycling74.Max             	0x0000000102cfebc9 external_load + 135
3   com.cycling74.Max             	0x0000000102e007b3 class_load + 301
4   com.cycling74.Max             	0x0000000102e00837 class_findbyname_casefree + 118
5   com.cycling74.Max             	0x0000000102ece4d5 jnewobj_enter + 421
6   com.cycling74.Max             	0x0000000102dfedcb object_method_imp + 340
7   com.cycling74.Max             	0x0000000102efff47 jpatchercontroller_entertext_imp + 493
8   com.cycling74.Max             	0x0000000102f072e9 jpatchercontroller_entertext + 191
9   com.cycling74.Max             	0x0000000102e3c790 TextfieldComponent::endEdit() + 590
10  com.cycling74.Max             	0x0000000102e5a109 BoxComponent::endEdit() + 99
11  com.cycling74.Max             	0x0000000102e3af94 TextfieldTextEditor::keyPressed(juce::KeyPress const&) + 834
12  com.cycling74.Max             	0x000000010353e7d0 juce::ComponentPeer::handleKeyPress(juce::KeyPress const&) + 320
13  com.cycling74.Max             	0x0000000103540eaf juce::NSViewComponentPeer::handleKeyEvent(NSEvent*, bool) + 847
14  com.cycling74.Max             	0x00000001035410fd juce::NSViewComponentPeer::redirectKeyDown(NSEvent*) + 61
15  com.cycling74.Max             	0x000000010353d130 juce::JuceNSViewClass::keyDown(objc_object*, objc_selector*, NSEvent*) + 304
16  com.apple.AppKit              	0x00007fff22d4eee8 -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 6482
17  com.apple.AppKit              	0x00007fff22d4d376 -[NSWindow(NSEventRouting) sendEvent:] + 347
18  com.apple.AppKit              	0x00007fff22d4c1f1 -[NSApplication(NSEvent) sendEvent:] + 3021
19  com.cycling74.Max             	0x000000010305df9d swizzle_SendEvent(objc_object*, objc_selector*, NSEvent*) + 109
20  com.apple.AppKit              	0x00007fff23024979 -[NSApplication _handleEvent:] + 65
21  com.apple.AppKit              	0x00007fff22bb469e -[NSApplication run] + 623
22  org.chromium.ContentShell.framework	0x000000011426fa0c cef_time_delta + 2877996
23  org.chromium.ContentShell.framework	0x000000011426e7d3 cef_time_delta + 2873331
24  org.chromium.ContentShell.framework	0x000000011422bf7a cef_time_delta + 2600858
25  org.chromium.ContentShell.framework	0x00000001141fdf1e cef_time_delta + 2412350
26  org.chromium.ContentShell.framework	0x0000000113f2ad33 ChromeAppModeStart_v6 + 6537459
27  com.cycling74.Max             	0x0000000103072b0e MaxCefEventLoopHandler::runMessageLoop() + 18
28  com.cycling74.Max             	0x000000010344b3b5 juce::JUCEApplicationBase::main(int, char const**) + 245
29  libdyld.dylib                 	0x00007fff203c1f3d start + 1

Hi Alex,
happy to see these externals being updated to Apple Silicon now, thanks great!
Just tried out the zero_latency_convolution_demo.maxpat patch on my M1 machine and unfortunately the output sounds completely broken. Chopped up audio and amplitudes completely out or range, like reading garbage memory - quite interesting actually, but not much reverb-like... I think the problem is with [partconvolve~].
[timeconvolve~] seems to work fine.
I'm testing on macos 12.4 and Max 8.5.1
best, volker

From Rod:

ok so gave it a good test today while filming and stuff, and I can confirm that your build doesn't blow up the scheduler when left for a long time.

that being said, one of the issues still persists, where after a certain amount of time, one of the (several) descriptorsrt~ stops sending messages...
I was using a hacky workaround as a safety net at the gig where connecting/disconnecting a bang object to the outlet would kick start the output, but for whatever reason (having changed nothing else), that now turns OFF the dac for a split second, causing an audio dropout (like when you connect/disconnect an audio cable).

The weird thing is that the scheduler is still running, with UI elements still working and everything, so it appears to be a completely different (yet similar) problem, isolated to just this one object (as i mentioned, among many).

I've managed to get a take or two where this part of the patch was working, but it falls smack in the middle of a 9min thing, and its a dice roll whether its still working by the time i get there (without the hacky audio disconnection)

Is there another (equally hacky?) way, to kick start the scheduler without interrupting audio?
Running in audio interrupt works, but it gets a bit crunch running this patch at 64/32 vector size (for feedback purposes)

This is the big of audio in question (the abstraction that's missing is a generic audio gate)

----------begin_max5_patcher----------
1543.3ocyY0zbahCF9ryuBFe1wi9Vvdp6tG5kcm8POryNc1ICFjcnECdDh1j
sSyu88UR.FbrcLIjz5CDgfWzidd+Tu4aWMa9px6TUyC9kfOFLa12tZ1L2T1I
l0b+r4aiuKIOtx8ZyKTesb0mluv+Hi5Nia5cwIeNXc.G09jh5sk0lbkwIFtY
V+Tl62o7q474A+ayixRceH3iecHt8qTYtO28pyamYWrI41rhM2nUIF+GAS3h
knEALNy9Gdj8JgrD08sAvjUzhEhctue0U1KKdY657rBU.Z4w2yjStmWbp8M5
4sui3t+PO+9l9L12aqyMYU4YoJcKPVsIoLuT6g.ZIIBgiDKfQTTTHh4GASgW
Df6AkRclpvDaxJKrhhNKkkDWjlAWTj1kIDQiHD6GOLxN1NJpYAGrLmmrqfEp
kZw6mCXIXa6k3ZLCYIRTuuZOcDP5iSIwvg.lAzaIDAfUtDvML1po.8kn253Y
5A76ktwGnpwc3QGuUYT5aTEwq7fEMcl+6Jyu+gfc5xDUU0MahMpGBdm1piAP
F7NysZU0sAWys2DaL1PDbXXpJI99.hc1aKySCvH6vsweVUuKfz4MYctRJqKL
8sLFZuPOkVuJaSQbtU2uezQc4v3w5yI3K4gTBGzIXjboThoBXLEispSJ+MHr
Shtrp5AHXKZjQddDsbLJQNRBAy5HDgbIKjK3xEARzaVTXyICAexzNqyKiMGc
2SFo8.Es2dfBaWbTTDGb0Ixyu+wS29uZWdlkCf3AizdvSCKNKefe99GjP7xH
LivDOcVY5DlUtLNcUbwlQZS3D4nT.cjTPzdOh9Q7Eno2jXKD4Mdi5Qbv50FW
v+JHHEgEvw.VRUUI5rclRcUP05sAgHDDEFgljZ1Xu.RhfvKoLhTRs4CIu1AN
9Rrt.RK5dhUouu1lN5qGUoMOLR9IOq539RL9KvWhgWJHgbHseH6xsibugKU5
AU46VO67CospxZcR6FosV7f8KDPLlrhtx3939BW68R2lklpFTlWZVks9iz9y
UpsUUdR69KEfP5p.7SfOWV9KGfuH7XUxOIgQv+3HLqm5SBvC1EulDF4hvC8s
COWjEO9sEOOkEN4sy.+fk5GN+bny8ObCZOfHOULIBephA3CxGua2WT5plUwg
NHK3m7GkTtvcaVg+V2AmlqUeIq888yDqgjPFHCTs1md5tPwbunkvBWTm0r1.
ubUSZrCRrzkZ8WqSyJ+.bj+5pa9SUQsOSGvFqiqyMC4vUaVmkm2cv2YcOAxI
2jXct+oKZl9flPvv3PWqGvTIw2NBX.m2yyoQFbqPLNKB4NYMSPjLtaTHgxoC
N7eiXjQ1vCfKK13ywSbmEpYV3zx6J0csAYIbh912u1TtQGmZ6SRmQnWE6oa+
A5gmdX0C91zzJSeS1NkweTmDedEv.BMBwvxHeWG3LozMhQhjNVhK5rZGHESx
wT2aPhnfftQbLRDMrWEwIIvtXfnPQNL25QYbWwxvHoet9RpxUaOTTYnP3wUH
BGF5GAeEaWS5KaEHbhk3GJMAfma8vBIwq5gBiwGzdEakgN4tIqv5ko5LGrc1
Q32os1SDYHidP+uVWVXZ0FPDf+ZmpH3CwEUAePsMaUYd59JFuDmgNCkS3Obg
1nC8HB67CBkHdXnezi1KG5QHZ0XB6Ooej+K8yqCwm88Z6usg6NmiQOd00fmA
WB92IAKvYUD1Cvbo9mG.Dvg7btVd0XmYp7HMO7jV299f1bYZ2vtyqbgLODZA
hKSh5GVv5lw33oFVCNP8wA1HXqWrGcOeyVeqGO5L9lxPaFsEGcziE6mxbbC8
NtLsn+L4Wr0kSm0qdflNsOcVV9FP7a40pqwmCUGKyHVJX9fpc.LxNE9U.f5x
uVLZDtGW7NeS5qDB+86iGO.QDnHFevOIkR79NDLFSmd.9dsR8LPni8n1e9RQ
rohmdv8Op77xuddzYKToJ6+Ts8fZIhGgPgmMCCTjmzGYAGhcw+3.iymzMP81
UJ86gBkFM4ZMEQN0OGRBxcHE2OZ1j.PsufBKBGQg1OI1NVc1BlP3+OABVwxl
pyA9N54aOCx78q9e.lOQMp.
-----------end_max5_patcher-----------

The latest vMSP help files each have a tab comparing the CPU usage to the standard MSP objects when 1000 objects are loaded. Not all of the vMSP objects are more CPU efficient with some being notably less efficient.
The below screenshot shows how each vMSP object compares to its corresponding MSP object in terms of CPU usage when loaded in the help files.

I wasn't able to build the external by following the provided readme file.
The VS solution references a .c file which is not present.

At the moment I get this error when I load in Catalina's Xcode (12.2)

and when I try to compile anyway I get 88 errors:
Error Group
The i386 architecture is deprecated. You should update your ARCHS build setting to remove the i386 architecture.

I presume there is a way to go and edit stuff but I prefer to point and moan.

Hi Alex,

I hope you are doing well!!!

You have advised in the past to not assign specific cores and to use automatic load balancing when using dynamicdsp~. I have recently acquired a M2 max machine and I was wondering if that advice is still valid with these or that specific assignment of heavy processing tasks to performance cores can be a good strategy nowadays or perhaps you have some notable insight into other quirks that are good to know when using these new processors in relation to threading and your objects.

Best, Hans.

When a host program (such as Ableton Live) is run in Rosetta, the externals crash that host program. I am requesting a build with the AVX instructions disabled so the externals are able to run within Rosetta.

Thank you!

When you try and do anything with thresholding and ask for more values than it can give it will spit out large junk numbers.

The last value appears valid, which shouldn’t be the case.

----------begin_max5_patcher----------
773.3oc2WF0jZBCDG+Y8SQFl9n0gffhc5K86PeqSGmHrhwCRnIAOs2b2m8lD
fdzdGFNO0YZePxj0P9m8W1cS3gwi7VyO.ROzmPeCMZzCiGMxZxXXTS+QdEjC
I4DocXdI7hBfo7lT+eJ3fxZ+qhiH0VpDEMAg8mfBz+h7QDVJRB.ZK+dDUgx3
fDsqhcGZOnegeTQStqcpxoLHgWwry2rFikDUxVJKak.RT0qynn3o5IeV7RSC
Nx2zDtXpO56MuDqpfWoxAkcI62NUBPpW4DEkydSSGM05g7069Xn2yRPYsJfa
LJUGyA6X8LFdb7XyiICjrL3dsDu.rqq1rADOgR3rDhZUIHRP63rr7iSIzMd8
yIbzBiqLGisN17PSSPPubJnwZsI0wRndd71jyI5Mb8Rgvx798a2COcKaGdFb
64oBQQzSfsEQSsgtVuHX4znyCZTlEYlFWDykhc3E91yKpBDNwUXcSPjiXLbe
3ZfPpec5BonaOkxHJ.gQ3SPpv.617h41lfqFoboSWR850yBtlj5y5Hcee2bJ
zt9qedNbZHYdtjpKplc6QUoP6DHfAhriqRDb8ncgs1xtMESBN2SEcNacPSb6
pZCmojzeZ4.1LAmHKzLVFonlYeQPI4dWDTV.RIICdAKSAYhfVp3BYCQQRk91
IDQ5pTX+D8MUH4GkP2yYcV1aVPcLyxkW45dmPnNaDQgukchfq7NQOA0c1Hdx
MfirAfKN6p.4T4PO.tes5h3Y+iFraKerhrluGL2KWsUihs77TzGvnBfvVQRS
QoUBKaNyrg5qPGFGesyF5WnNaUy+eKYHLH9lkLzuVcOSDeKRFrJa+5v+5CUs
fxX+O4tjWIRZc4l.AzyqeMxUTl0q6LFiqXFzqt0NTgL0ecpjoBx6WoYCPo4W
.gL2k1M7tDBMD1EeIDZHnqc079TBODkhtDJMTWBeADB6RnWFfWmBSJK2CBYy
nsZnKRtiKLcimX6RY0csUP7DvdZ63qsPD5ZiJcwpJQckhCyquziWAOEDrJps
TyXixON9Wjrdx0O
-----------end_max5_patcher-----------

In addition to pitch, it would be good to have sigmund as a usable algorithm inside the descriptors~ paradigm.

Very happy that Win version fo your external are coming @AlexHarker !
Thanks.
Just found a bug i reported in the issue title.
ibuffer~ help file crashes on Win11 64bit as soon as the dac~ is turned on.
I'm on latest Max 8.3.2

When loading a 24bit Wav or AIFF sample into either ibuffer~ or ibuffermulti~ and playing it back using ibufplayer~ it distorts massively. This does not happen with 16 or 32bit samples in either format.

It would be nice if there were an option to crossfade between patches when you switch (probably just a time / fade type and a way to switch on/off)

ibufmultitable~ is adding periodic sections of silence rather than a smooth continuous output as it should. In this screenshot it should be outputting the waves stored in the buffer shown at the bottom.

Hi Alex,
Are you planing on updating ajh.wiiremote as I see it's in the legacy folder?
Is it just a case of rebuilding and checking it works with all the controllers again or would there be more work todo?

At the moment if you double-click the object and are looking at the spreadsheet view, and you (single) click on any of the fields, it zeros out that field.

Double-clicking it zeros it out and selects the field (which seems like expected-ish behavior), but having a single click do it feels a bit severe.

Also it feels like the expected behavior here would be single click = nothing happens, it just selects the field, and a double-click selects the existing entry, which can then be edited (or zeroed out).

this used to work in 32 bit and isn't in 64 bit.

1. feed descriptor~ pitch value for no pitch (0.000000 something) in entrymatcher
2. try to match with pitch == 0.

in 32 bit, it yield them
in 64 bit, it does not. I replaced with pitch < 0.001 but I presume it is either an output value change (0 vs 0.000000xxx) or a match tolerance. Either way, I'll replace in my patches but I'm surprised.

Thanks for the work you've been putting into this. I'm wondering if you have any idea about when/if you would be able to provide a 64-bit version of these externals?

Additionally it would be nice if they could be distributed as a Max 6.1/Max 7 style package.

Thanks!

Hi Alex,

It is very nice to see the updates on the objects. I have just discovered schedulemessage and I was wondering if it is possible to clear future events from schedulemessage, like pipe has both the 'flush' method and just 'clear'. I could not find it in the code, so maybe this counts as a feature request?

Thanks.

Best, Hans.