Fluid.buftransientslice~ debounce default is too short

25 samples is way too small a default value for the default debounce time…

I presume this was meant to be 25ms when it was being coded up as that seems a bit more reasonable.

Dear @rodrigo.constanzo
As written in the file under known bugs, debounce is actually not behaving at the moment. Go figure. @a.harker said he might have sorted the root of all evil yesterday. I need to get the updated code, compile and test. @weefuzzy will let me know when all that is ready, but at the moment the team is in deep transition to a new code base so I will wait patiently.

1 Like

Ah, don’t know where “the file” is, but didn’t see any mention in the help file.

Looking forward to the next alpha (will this just be a refactoring, or will there be new objects? (and/or new helpfiles?!))

in the post announcing alpha02 and 02a

What’s the problem with the current helpfiles?
(joking - we know they are a strange blend of help, tut,demo and doc and will be refactored after)

Next alpha will be post refactor, and might include the 4 new (and last for now) objects in the pipeline for the first toolbox. What they will be is a secret for now, otherwise you might get your expectations all high and then moan if we cannot deliver despite the incredible hard work the team is putting behind it all…

Ah cool, looking forward to that.

At that point I can start trying to formulate what I can do with the existing tools (within my “batch”).

Heh, these helpfiles had me literally apologize to @a.harker for ever giving him a hard time about his help files in the past…

1 Like

you’re so high maintenance :wink:

you can start already. the new objects are doing the same tasks, just with different algo…

Look at you, Mr. IRCAM (it’s good enough to make cool tools, forget the documentation…), hehe.

Hmm. Well I hope/guess something cool will come from the different algorithms and/or how they are implemented.

At the moment nothing has really struck me in terms of what I would want to do with it, aside from some of the experiments I’ve been posting. All the offline stuff is cool, but without database tools these aren’t quite as useful to me at the moment (and I’m not going to reinvent the wheel with you guys making tools for that later on), and I’m struggling to find some real-time use cases that are compelling (to me (at the moment)).

I did have an idea, which I still like, it’s not just feasible with the batch1 tools.

I’m sure you’ll find one, since creativity is stimulated by constraints, and that is yours: it is a decomposition toolbox, as it says on the tin :wink:

Indeed, but based around a clear workflow/paradigm (offline composition-y). :stuck_out_tongue_winking_eye:

almost half of the objects are real time… and I used one of them live with WetInk (a clever buffer shuffler)… live, real-time, buffered, windowed, all of these are possible and all of these have examples, so the ‘bias’ is pretty wide… there is actually not much for offline composition at the moment as it usually relies on large database processing, but that will come (with the command line interfacing and database managing in the second toolbox)