@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?)
@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?)
Yes, that would be helpful, cheers. Just bump this thread for the time being.
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…).
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.
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’?
Plectrum is a fancy person’s word. I’ve always been accustomed to ‘pick’ but that’s just my opinion man
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
/.maxpat
s though as .json
files?
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)
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.
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.
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.
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.
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.