flucoma / flucoma-max Goto Github PK

I assume simply adding your misc folder to the release build will fix

Hi, I'm trying to build this on my own because my cpu seems to lack AVX support. I'm not using visual studio but in the cmake files for the single projects the Visual Studio flag /wd4814 is added which, in my case leads to an error while building.

Is it possible to disable the addition of this flag? Thank you, O.

On the EB"U/ITU tab there is a typo in the upper text next to the one - the work "peak" is typed as "oeak"

It tries to load the path related to the computer that does the packaging. The harrowing regex sub patcher should just be replaced with some conformpath magic.

Love the patch. A few problems, from our emails

1. the text from the doc is cropped (see picture below)
2. "an histogram" should be "a histogram" and "class" should be "object" as I was told by @jamesb93
3. there are bufcompose errors every time it loads a file
4. in the 'more details' we need (like the fluid.chroma~) a way to adapt to varying number of chroma bin. the code is almost there. it will be good to show users how to dismiss the spare channels.

Given that this seems to be coming up with increasing frequency, we should see if it can be made easier / more automatic for the build to do the right thing.

There isn't (yet? I think?) a silicon native version of Max, and I don't think we can yet build for it, so I think we just need CMake to set the OSX architecture to x64 for everything on Mac. I'm not sure of the practicality of being able to support x86 out of the box as well, but I think we had to abandon that already.

We also need to turn off AVX for M1s, because Rosseta 2 doesn't like it. That's a bit more involved, because we need to figure out the platform, but this approach of running uname -m looks hopeful.

Situation: Max7 does not respect the new line so the whole dataset is put on a single line. In Max8 it behaves ok. This is true both on Windows and on MacOS. I don't know if there is anything we can do.

How to reproduce: print any dataset that has more than one 'Point' and observe the Max Console.

fluid.buf2list will report that the buffer it is pointed to is zero sized when you create the object. This is not a problem, in my opinion, because you are likely to resize the buffer with analysis before you exfiltrate the list with fluid.buf2list later. The error should be reported when you send a bang to the object if indeed the buffer is still zero-sized.

Steps to reproduce:

1. Create a new patch
2. Create a buffer with a name like buffer~ foo. Do not specify a size explicitly
3. Create a fluid.buf2list object like so: fluid.buf2list @source foo
4. Error will red in the console

This is perhaps more esoteric but when building with the new 8.2 SDK the binaries get code signed automatically. I'm not sure where this occurs but if I make intel binaries with the old sdk this does not happen.

I can verify this by running codesign -dv --verbose=4 path/to/mxo on the binaries. When I use the new SDK the binaries are signed with what seems to be a bogus identifier matching the name of the external. Max infinitely complains about not being able to load the external due to system security. I can fix this by running:

codesign --remove-signature path/to/mxo

Just flagging this now as something to test and to perhaps work around.

Max 7 is not happy with this shortcut in the init file. @weefuzzy said it was another problem, so it is here :)

In Max7 this is happening twice when we load our package. It is not pretty.

In the basic tab when I hit any of the options that start with 'reset' to try some different parameters the display shows some red lines that flash for a moment and then disappear. Some of the lines stay there, I just don't know what the flashes are and if I, the user, should care about them?

Is this going to be replaced with fluid.waveform~?

the same way we have multithreading one, it would be good to have a shared multichannel explainer, especially on channel orders, instead of having examples for each buf*process.

The same would happen in Pd and maybe in SC @tedmoore ?

In this very simple patch, analysing digital silence, I get expected values in SC (the minima) but not in Max anymore (random spikes at 0. 0. otherwise the right values). It used to be fine.

----------begin_max5_patcher----------
659.3ocqUssaiBCD8Y3q.wyjHay88WYUUkC3x5JhMBLcS2plu80drgFRHoYi
VdvXOLy3yYNiMe36EtSdfMDF7ifeF348gumGXxXvys1KbO8PUKc.bKTv9sb2
qgQ1OoXGTf4Adyw.zjY4npkoTu2wro17YAsML3ImCcTU0u3hlm6YUJqOj33s
nn.bQh4UB1LRHaQywHF2yE5zB3.+kQ6lsvJuF.kFnahCMl9z22LDcmjj8mZZ
0wI1zJqLX+qzuB5wFnpAbNf6jzow0QOYUzitD8YnGA96YCCzF1EhzFbZ9VBI
KsrHXSLVWuyw3xzqpZ2VuPVFmkCxVY9sELx8JXjGgwWoq7k1Qd81V4XsPWRN
dUh1xGTgQeGgsMnDLzfVT9HMnjU36BIFRlFOhyOUB.xXeYUXPN1WMQCW5hB9
BS0rAEWPUbo3Tmz9fCdZ0B88tQw2y93.yEDj108Fqev4MrGZA8UYuYYQDrjK
rKgJYXO6M9j+XqIZuVhTZ8YrG.V3grjParxZVuXjCN6anmdOGTu2ddUUP2aC
U2MkYZw.5nYyKzwV0xJvtlJYqER5y6PS+7.Za5bovz8Ad9LWXHoqngr9MMfO
owgVUwDpSxNZagwsh3RBNyLKGUVfRbQYqlQN0pWGJPMfGNBrWidf8nyT2EDF
5VuEkW.oDRbJozfl3bRZBLijmjh+eCqEWesNv92qw6Zdg21NSHu4boSl6hfv
ldZMWia28DN9im0jL8SdzpyNYqbgQlBKunPW4hVc1kgMEEoDgKAsO1o8lYZS
3yhhJZrEYRtgzNqc8xNY+zwQcnky9OpjyD0IEtSmWU9Vd539TQ6sd2c2EnYI
51JDAlo4rFyOZmk8VF3+CFPMzQs2cA+Fw+S++ZRrI3C
-----------end_max5_patcher-----------

Is it possible to compile only a single object from the repository? I intend to make a few buffer manipulation objects and I feel like this would help speed up the iteration between compile/rerun max.

Linked to #47 and is because loadbang of the buffer~ wave doesn't actually work in the help file. Something to do with threading, despite use of deferlow.

• Writing on second tab is redundant and covered by the learn reference. Keep first sentence
• on/off threshold needs to be explained (but how without context?)
• Fast and a slow envelope follower... The difference between the two...
• Dynamic threshold
• Comparing sudden changes
• Slow one provides a context which the fast one is compared to
• We need a tight narrative to explain the relationship between the parameters
• dB amounts don't match up with the parameters
• slide~ addendum to show how ampslice~ works

Patch and Crash attached. When I try to call load (incorrectly albeit) using a trigger object Max is sad and crashes.

----------begin_max5_patcher----------
1243.3oc6YtsiihCD.84juBDOtJaD9B21ekUihbBNY7LD.AN8zyLZlu80TF5
lzcHXnqr6KqTDHb.Jeppbcw7y0q72W9rrw26u79auUq945UqfgZGXU20q7OK
d9PtnAtM+B42J2+E+M1+RKeVCCmIOJqyK+V+eTb4rpHWpgGhzMXkPe3yphS6
pkGzVgRhC1FrwiDvZOExaORoaC79zqunxK529lrCo+dkz9Z78e4ATYvDxLI+
Spe6P+Z851CabDv8Wz5xhYyACl57H..d+w4hwdQwoahRRp+KBuVbVpk06jEh
84vSFr.NGwPp8xKEYdGxkh54aLo.3j1iQwSXKoioDZm.9a77sygapMh8wj38
d4yEUNMxZuAVooaCWFqfAeyH9uIQHhYsQ1RuiJstVTzbrr97MYlNNyLqONi.
nmltT6637FhNuVeo4wIMxFSJEhIEQwmSNhbVUqJzy18k.Vu3jPvhNEhA2fgf
kvvYYSi3j7cPLd3l6Xm31jFIL3DKD0bGbJpgXTy1BYielXMTjzkBWqyws3ik
h6ZshYuLiGk.9fw.arTTMerDDbOckjPVv.RBCvkDLy08GlJsB1tTKkcgFew7
czDMdDuQLiHpLEGM+kaQsoviRsQQvMVBisD5TZn7ttWWi5GfLL1uYa8.zRC.
nhCff8owCXyTPvI3kSCF91uQNtbUg7PYdYcWAesuJi6.ILJIhFyCCRSB32bH
x.4cyfTada0uElxbAEQuJPcpnzfUt5vWGZCFpno2sJ4dGkxx7gu.POuKSnE1
oSKS++OG+48I7V39YUitzeYt2I1h1X7kVsVmO3n4KIHFg5G4aaLtwROxrokY
iSYCBGFhdsozDD4LScPucQgi6vzVgGOF2sE.+1pffGKyTFFYayfguojhYI5m
j5kgYWmxovoPJplRRJxdqKjtPZeoe2ee.3iQWqrUkEh5uClyM2wrRheol.wS
xrclwLSmcBSi8p8FmwlNx6Peku77dY1fDf2M63v+7rnp5psXxpnwxiJ6x4pk
tGD1cJD4lFHOf.CKfw9UL1sQLB+8YgvPjyi4WTYaaiLzH0+1qXrMVhLsQMAZ
yfPHSPLapcSy1nwn3i5VWLbG0f.jiqBldOmnLHUGw5AflicJ516VFE4ldR98
bM18jl.mRYOVac7iySezjgSuC4DaZPRP7C1SeH8vM.cv8lO3CLOaG+ZURS4k
5C8xy94Tf586DSlrQqJDsYsFbOD+w6IvU4jD6ffnXHnTGDT+r4iiDYBIwtVA
eVkUUZZGoyZQsejAtsj+THF4UWj18smhd2EIV+Ld7qW8Zu30Yx5w+FR3BH4A
AXbWFyP1MtxtA9cvCW8d3IeL3CcYkQDF9QQNnlIX3wZpQvg0FnwzjZuTDjTq
dgNERgXfD2AjvfHhKDwQPPLWHhccP.jBsvbwSj8uGjIWcSHEBg4TpnfGgnoI
tD5lgf9k6REDuIKHRNQtIZx+Yl1wD8GboShKhFi.Qv72oBbHXHIWch9XKLbI
wDMACI4h2IEijsDWpSihg1i3haONkp3TADAXHo.Gx2RvHToKJu2q6rs3Ippd
RV2zcyfHL829E6GsKYCbopvdIrkD90xmT82OrOf9hZSqqZSeqWpseDtmi391
GszDZp3hpKvnANiHgdma+fcMUBKGPK1q+05+Aun5FOC
-----------end_max5_patcher-----------

The sound file that loads with the helpfile is silent when I ask for just the sines out of the object. Just setting a different soundfile as the default would solve this.

My guess is that perhaps the fluid.demosound maxpat saves it as an index in the folder and now that we added more soundfiles that index changed and so it's just pulling up the wrong soundfile?

It would be advantageous to be able to view data inside fluid.dataset~ by double clicking the object. Bonus points if the data can be edited, although read only would be the main use case. This would save on creating dump > object > route dump > dict.view patches to verify that patching did what it promised you it would.

As per this forum thread:
https://discourse.flucoma.org/t/verbose-information-when-hovering-over-outlets/

When hovering over the outlets for Max objects, no information is given about the output, which is unlike most native Max objects.

It says it's the id of the nearest point. Maybe this has already been fixed, but I figured I'd flag it here for you to know rather than digging through commits...

@jamesb93 and I think not; that the FluidPlotter object should have a setPoint message that overwrites a point if there is already one being plotted with the same ID. This issue is mostly a reminder for us to change it...

This is a very-very minor feature request, and I don't know how many Max users are annoyed by this, but the F (Shift+f) shortcut is really annoying because it overlaps with the "adding a connected [flonum] object" shortcut ("patching mechanic"). I very often want to do that, and I would never want to spare the few extra key strokes to make an actual fluid object (since, at least for me, it is typically not what I speed-patch -- the quick attached [flonum] is, and not just in flucoma-related patches).
I have always been deleting init/fluid-keycommands.txt after install, and it is no problem to keep doing that, I just wanted to voice this, maybe there are other people who share my opinion.
Go FluCoMa, keep being awesome!

In the max helpfiles for the slicers the number of slices reported is one more than plays back on the "musical example" or "basic example" tabs. It looks like there's no mechanism to look at the length of the buffer and therefore provide an endpoint for the last slice.

When I start making sound I heard the piano synth tones and the guitar strum. Both sounds I know from the tool kit, but it led me to think that there was some sound playing in another patch or something so I went looking for it.

The helpfile should just make clear in the text that both of those sounds are expected.

In the grand scheme of sharing pre-baked datasets for demo examples across CCE (which is a great idea) I think we should put them in the core repo for 2 reasons

1. like in #110 it saves duplication
2. like anything that will rely on audio loading like this, we could make it sturdy to changes in the audiofile folder by making a labelset of the actual files loaded in that dataset so we are consistent upon reload.

There is no circle with a 2 in it. Should the 3 just be a 2 or is there another idea that is missing?

Whenever I call the write method, for example with the mlpregressor~, I get the error:

fluid.mlpregressor~: Could not open file for writing

I have checked the system security preferences in order to rule out some permissions, but I have given full disk access to Max. What would be a way in to debugging out any stupid decisions I may have made patching?

Hello,

When writing a dataset~ to disk, I need to manually add the extension .json for it to be able to be selected in the open dialog when sending the "read" message.

Should probably be default when writing, or maybe add a "writejson" message like buffer~, or just signal in the docs?

Thanks,

It would be more robust to retrieve the location output and be able to leverage that in the CI runners. It would reduce errors like #90 and overall reduce code to read IMO. This is not specifically related to Max but I will add this issue to the organisation wide tracker too for CI.

Linked to #48 and is because loadbang of the buffer~ wave doesn't actually work in the help file. Something to do with threading, despite use of deferlow.

bufchroma is the one I noticed.

Hello,

I'm getting the new beta running on my machine but am having trouble compiling with flags that previously used to work. I run the recommended commands before make install and this is the output.

❯ make install
[  3%] Built target HISSTools_AudioFile
[  5%] Built target HISSTools_FFT
[  7%] Built target describe
[  8%] Linking CXX CFBundle shared module "../../../../externals/fluid.ampgate~.mxo/Contents/MacOS/fluid.ampgate~"
ld: warning: ignoring file /Users/james/dev/software/max-sdk/source/c74support/jit-includes/JitterAPI.framework/JitterAPI, missing required architecture arm64 in file /Users/james/dev/software/max-sdk/source/c74support/jit-includes/JitterAPI.framework/JitterAPI (2 slices)
ld: warning: ignoring file /Users/james/dev/software/max-sdk/source/c74support/msp-includes/MaxAudioAPI.framework/MaxAudioAPI, missing required architecture arm64 in file /Users/james/dev/software/max-sdk/source/c74support/msp-includes/MaxAudioAPI.framework/MaxAudioAPI (2 slices)
Undefined symbols for architecture arm64:
  "_class_dspinit", referenced from:
      fluid::client::FluidMaxWrapper<fluid::client::ClientWrapper<fluid::client::ampgate::AmpGateClient> >::makeClass(char const*) in fluid.ampgate_tilde.cpp.o
  "_common_symbols_init", referenced from:
      _ext_main in fluid.ampgate_tilde.cpp.o
  "_set_zero64", referenced from:
      fluid::client::impl::RealTime<fluid::client::FluidMaxWrapper<fluid::client::ClientWrapper<fluid::client::ampgate::AmpGateClient> > >::perform(object*, double**, long, double**, long, long, long, void*) in fluid.ampgate_tilde.cpp.o
  "_z_dsp_setup", referenced from:
      fluid::client::FluidMaxWrapper<fluid::client::ClientWrapper<fluid::client::ampgate::AmpGateClient> >::FluidMaxWrapper(symbol*, long, atom*) in fluid.ampgate_tilde.cpp.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [../externals/fluid.ampgate~.mxo/Contents/MacOS/fluid.ampgate~] Error 1
make[1]: *** [source/projects/fluid.ampgate_tilde/CMakeFiles/fluid.ampgate_tilde.dir/all] Error 2
make: *** [all] Error 2

Looks like there is some funkiness with architecture flags/settings

Just a couple of comments on the fluid.plotter help:

• The numbers-in-bubbles paradigm we've adapted from built in help normally signals (to me) that I, as help file reader, should do something. So I find it confusing when they're just there to draw my attention to the various stages of a flow.
• I think illustrative comments like that are better represented using a bubble
• Also, having a bunch of the numbers in circles in a funny order is more confusing than not having them at all
• Consider making the red warning thing on tab 2 much bigger, and possibly moving that warning closer to the action for the (1): my eye went nowhere near it when running the patch, so there was a longish moment of "where's my plot??"

The overview for Max currently is missing some things:

1. fluid.grid

2. fluid.stats

3. fluid.bufstft

We also need to agree on the headings for these as I moved some around in Max as things have transformed from abstractions to full blown externals for example.

The reset message is broken for shared objects (fluid.dataset~ and friends). The intended behaviour is that an object will revert to the state of its defaults, modulo what values were set in the box at instantiation time.

----------begin_max5_patcher----------
652.3ocyWt0jZBCE.9Y3WQFdl5PB26S6+iN6rSDitYKDrIAqs6r82dyEQocY
oHnVeAMGOgy46bKwWcc7VVumH7.eF7EfiyqtNNFQZANGV63Ug2WThEF07Jpq
pHLomu82jj8RibFdEtUHqohxJIRyNfmDV2HakFbPJckY20Ke4Svr18uEKKdl
x17DmTHsNGJIcQfO.kko+.FGXVodBdTum2bc0O7mIDU3uR.XPwyX1FxLoIcD
zDkeMoQ9LU.3DYCmI.xZ.kQkfc3xFh.fE.x9sJGhrBztwRJiTT2vL6F058bh
P8xwRZM6od0Xhwm3AhOvbSDAFD2I9DFdGmsiFhlTj1+SCtDI6JhPfO4tGgQm
lj8BApWHf8.Apc+V8j+XKwRfmG3wA3Cla6MSLoISNCgtv7sTaWA8mDUnyGTR
vbFGKIffEvYRMbhTGDrH11CGeJsNUrYjuqbl2Q85xF5pEUkptvMpLrnl+KvC
cgOD7voHSbvfsxinzN78wmzOL7rT0234qcxZrT+kwTkDlYKVfn1hk6s1fjIV
ODl0Yl0LKG9H7T7rlS9FHJXdLFMMFygmFjkDe8J3W1rtZcQgpVuEXz0nzFdo
JsismSklXq.BlUoMVJ4Mzy37ndxuiYRt1NcKp792.FE18HLz+Q.yNG.ONgbH
DCsCjPY2KHleNHd7LgQfXb9PHZd2ltr+5+EXdiZ4+I2h5FdQqm0dMBPvQWbE
QHoLy8G6nTpUmdCsi1PvajgxuQ1I6FYmjQXG3EvNQ2H6fljcrE53sa2Q3hCJ
aLgpU9kZSaUluYIkYWZZRUWwXGsUenUDlq50jpFsFtwu71mXOg0qpdEgyTiB
zJ6poSYSybBFVcH+VrEDy3D22b+MP8Un7C
-----------end_max5_patcher-----------

I think this is because I didn't consider that for shared objects we are now dealing with reference semantics for the params, and so the the snapshot we take at instantiation time is effectively a pointer 🤦 Rather than start with making arcane assignment operators for the shared params, I think the neatest solution here is to change the overall behaviour to take advantage of the from/toTuple methods recently introduced, and keep the snapshots as tuples. This means that we can rely on parameter updates propagating properly when reset is called.

There is, of course, the potential for confusion here when multiple boxes pointing to the same name init with different params. However, I think the simple approach is the one to follow here, which is that the late bird gets the worm. i.e. each box still stores its own values, and the last one wins.

Where the user boosts the residual to greater than +2 dB, I couldn't hear it until about +18 db, +30 was even more clear.

For CMake generators other than XCode it doesn't seem like the variable substitution for our Info.plist works properly, so we get left with things like

	<key>CFBundleIdentifier</key>
	<string>org.flucoma.${PRODUCT_NAME:rfc1034identifier}</string>

in the file.

using fluid.chroma~ in max and reducing the number of chroma bins leads to an output of the same size of max_chroma (as in the helpfile) but the last values are repeats of the old values from before reducing, and not zeros (which is not what I expect).

Latest beta - fluid.chroma~: Fluid Corpus Manipulation Toolkit, version 1.0.0-TB2.beta2

Situation: Many DataSet examples and some help files use the (linux-biased) /tmp folder to write temporary files. On Windows that doesn't work.

Solution: find a way that writes temp files in a system-agnostic way and replace them everywhere.

When the 'basic example' tab is opened the sound file it suggests is Green-Box639.wav, however when that sound file is used with the parameters loaded into the fluid.bufnoveltyslice~ object it returns just 1 slice.

I think it would be good to either suggest a different sound file right off the bat, or have settings that will work better with this soundfile.

On macOS 11 (Big Sur, Apple Silicon, rosetta), creating an instance of any FluCoMa external crashes Max.
An excerpt of the report is shown below:

Process:               Max [12003]
Path:                  /Applications/Max.app/Contents/MacOS/Max
Identifier:            com.cycling74.Max
Version:               8.1.10 [f1acba9] (8.1.10)
Code Type:             X86-64 (Translated)
Parent Process:        ??? [1]
Responsible:           Max [12003]

Date/Time:             2021-03-22 08:45:59.526 +0100
OS Version:            macOS 11.2.3 (20D91)
Report Version:        12

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 [12003]

Thread 0 Crashed:: CrBrowserMain  Dispatch queue: com.apple.main-thread
0   org.flucoma.${PRODUCT_NAME:rfc1034identifier}	0x00000001595c9430 fluid::client::FluidMaxWrapper<fluid::client::AmpGateClient<double> >::makeClass(char const*) + 432
1   com.cycling74.Max             	0x000000010097506e external_bundleload + 1036
2   com.cycling74.Max             	0x0000000100974bc9 external_load + 135
3   com.cycling74.Max             	0x0000000100a76783 class_load + 301
4   com.cycling74.Max             	0x0000000100a76807 class_findbyname_casefree + 118
5   com.cycling74.Max             	0x0000000100b444a5 jnewobj_enter + 421
6   com.cycling74.Max             	0x0000000100a74d9b object_method_imp + 340
7   com.cycling74.Max             	0x0000000100b75f17 jpatchercontroller_entertext_imp + 493
8   com.cycling74.Max             	0x0000000100b7d2b9 jpatchercontroller_entertext + 191
9   com.cycling74.Max             	0x0000000100ab2760 TextfieldComponent::endEdit() + 590
10  com.cycling74.Max             	0x0000000100ad00d9 BoxComponent::endEdit() + 99
11  com.cycling74.Max             	0x00000001011819fb juce::TextEditor::handleCommandMessage(int) + 523
12  com.cycling74.Max             	0x000000010116860b juce::MessageManager::AsyncCallInvoker<juce::Component::postCommandMessage(int)::$_7>::messageCallback() + 59
13  com.cycling74.Max             	0x00000001010c02a8 juce::MessageQueue::runLoopSourceCallback(void*) + 120
14  com.apple.CoreFoundation      	0x00007fff2045231d __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
15  com.apple.CoreFoundation      	0x00007fff20452285 __CFRunLoopDoSource0 + 180
16  com.apple.CoreFoundation      	0x00007fff20452005 __CFRunLoopDoSources0 + 248
17  com.apple.CoreFoundation      	0x00007fff20450a4d __CFRunLoopRun + 894
18  com.apple.CoreFoundation      	0x00007fff2044ffe2 CFRunLoopRunSpecific + 567
19  com.apple.HIToolbox           	0x00007fff2891e630 RunCurrentEventLoopInMode + 292
20  com.apple.HIToolbox           	0x00007fff2891e282 ReceiveNextEventCommon + 283
21  com.apple.HIToolbox           	0x00007fff2891e14f _BlockUntilNextEventMatchingListInModeWithFilter + 64
22  com.apple.AppKit              	0x00007fff22ba59b1 _DPSNextEvent + 883
23  com.apple.AppKit              	0x00007fff22ba4177 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1366
24  com.apple.AppKit              	0x00007fff22b9668a -[NSApplication run] + 586
25  org.chromium.ContentShell.framework	0x0000000111d67a0c cef_time_delta + 2877996
26  org.chromium.ContentShell.framework	0x0000000111d667d3 cef_time_delta + 2873331
27  org.chromium.ContentShell.framework	0x0000000111d23f7a cef_time_delta + 2600858
28  org.chromium.ContentShell.framework	0x0000000111cf5f1e cef_time_delta + 2412350
29  org.chromium.ContentShell.framework	0x0000000111a22d33 ChromeAppModeStart_v6 + 6537459
30  com.cycling74.Max             	0x0000000100ce8a8e MaxCefEventLoopHandler::runMessageLoop() + 18
31  com.cycling74.Max             	0x00000001010c13c5 juce::JUCEApplicationBase::main(int, char const**) + 245
32  libdyld.dylib 

related but different to
#113
we could have a vignette on fft parameters (and the padding for the buf version)

the 3 shared vignettes (blocking / mc buf process / fft parameters) would probably benefit from a learn page too to streamline the whole thing. I remember we spoke about it all in meets... @jamesb93 and @tedmoore does it make sense?

At the top of the combining columns tab:

"transformjoin "

"destination" is mistyped.

Self explanatory.

I tested this Launch button in my Max Package Manager and it did launch for me, so maybe it is fine.

But since one of our users said they were having a problem with it, the next time you're in Max can you just check and see if it works for you?

If it works for everyone, I'll close this!