Help File Grievances

@weefuzzy, where would you like me to report typos and other non-code-based problems I run into?

(just keep bumping this thread or somewhere else?)

1 Like

Yes, that would be helpful, cheers. Just bump this thread for the time being.

1 Like

The reference file for fluid.spectralshape~ still refers to spectral bins as units.

And the text from the live.tab in its main helpfile probably doesn’t need the numeral signposting ("First, we have…, Second, we have…).

1 Like

fluid.sines~ help file has a weird problem where it thinks I am on Owen’s computer.

You can see I was getting the error and went I tried to select an audio file. I was able to remedy it by opening the bpatcher, saving, exit and then use the interface. I’ve honestly never seen anything this wacky even after making around 80 FrameLib help files. I’ll bump if I dig deeper in any way.

Actually, it works when I go into the bpatcher and force loadmess path to output again. I think its probably cached the file in the bpatcher while youve been working on it @weefuzzy and for some reason loadmess path isn’t calling correctly when the patch is loaded on another machine.

Cheers for catching this @jamesbradbury. I shall have stern words with it.

1 Like

in fluid.bufnmf~ ‘actiovation’

1 Like

in ‘fixed bases’ tab of ‘fluid.bufnmf~’

‘spectral entroid’

1 Like

Whilst we are looking at that “pick” is a North American word - in the UK “plectrum” is more common - as the latter is (I believe) understood everywhere might it be a better choice?

I was reading this and looking forward to a kind of “picktral entroid”-type joke coming at the end, I found myself disappointed at your earnestness.

I hadn’t heard plectrum until I moved to the UK, but it is possible that it would be more universal? Or maybe “guitar pick” to it’s more precise and doesn’t confuse with the verb ‘pick’?

1 Like

Plectrum is a fancy person’s word. I’ve always been accustomed to ‘pick’ but that’s just my opinion man

2 Likes

I have to imagine there’s going to be dozens of similar typos in there, which it would be likely impossible to catch them all.

Is there some kind of spell-check script that things can get run through, even if just shoving the .maxhelp/.maxpats though as .json files?

that would be great indeed… I’m sure @weefuzzy has something along those lines up his sleeve

American or UK spelling though?

Sorry, I mean speulling.

fluid.bufonsetslice~ doesn’t say what the available metrics are anymore. The .helpfile has no mention of them, and the reference file says this:

The metric used to derive a difference curve between spectral frames. It can be any of the following:

(nothing)

1 Like

fluid.bufampslice~ says “Schmidt trigger”, but the correct spelling is “Schmitt trigger”.

The “Discussion” section of the reference file also says “The example code below is…”, where there is no code in the reference file. (I guess this was copypaste from it was in the help file).

Also, I appreciate that there is a UI bpatcher in this helpfile now, but it is super annoying to navitage (not unusual for rslider), but specifically because it resets every time you update the settings, making it difficult to zoom back in to where you where to compare the differences, again, because rslider is super annoying.

Pretty-please can this just use a tweaked version of @leafcutterjohn’s buffer/slice visualizer from this thread? This is sooo much more easy to navigate.

Lastly, the “musical example” subpatch should have a visualizer and also use audio that shows off the separate onset/offsets created by the object (i.e. something with sounds, and space). As far as I can tell, the sound we hear from the slices in that tab could have been generated by any of the fluid.buf onset objects since the Nicol-LoopE.wav essentially has the offsets where the next onset begins anyways.

1 Like

Hell, can (an updated version of) this patch be in every fluid.buf onset object? Perhaps with a curated set of sounds and settings that show off the features of each algorithm/object.

1 Like

Thanks for all these Rod. The reference file thing is an artefact of this text coming over from the SC help (where there is indeed code below). It’s a good cue that we either want a tutorial file associated with the reference, or to point back to the help.

I like @leafcutterjohn’s slice visualizer, and I agree that something like this would be super handy. I’m inclined to try and make something more generic (but similar) in JS, if only because lcd always makes me sad when I try and use it. I also agree that rslider is not a nice thing – that one’s on me, hacked together and never improved upon.

1 Like

I think I mentioned this to PA (and/or in another thread), but I would imagine you guys would have some kind of text database that autopopulates/updates with environment-specific modifiers so you don’t have to manually chase all that kind of stuff down.

Yeah totally. I guess what I mainly liked was the easy/intuitive navigation, and the fact that it doesn’t re/de-zoom if you run a new query. And for something like fluid.bufampslice~ where there are onsets and offsets, showing selection onset window selections (rather than an +1 tick followed by a -1 tick) would be handy for tweaking thresholds and parameters.

Something generic would be useful though, as it can be quite handy inside “actual” patches.

1 Like

That’s a very generous thing to imagine of us. We’re about halfway there, but it was necessary to do the docs by hand the first time round, if only to get the shape of them. I do indeed have a database (seeded from the SC text, which I’ve been cleaning up), but not yet all the environment specific goodness one would like, and not generators for all environments yet.

2 Likes