Fluid.waveform, "latch", always on ( pure data )

Bug Reports and Issues
1

Hello,

in the html documentation I read that “latch” option is present and “zero” by default.
But the object returns the mouse position on mouse up, even when “latch” is 0.
I would expect not to return anything unless “latch” is 1.

Could this be a bug ?

2

could be - I will investigate in June (messy until then)

1 Like
3

ok I can confirm, but looking at the code, I don’t know why :slight_smile: Pd GUI coding is so ugly with TCL being sent strings… anyway, not your problem, I’ll chase that one deeper and try to fix and report back

4

ok it is a Pd thing - it sends a ‘motion’ action after releasing, so I need to invent a new release type under the hood. fun.

before I do so, let’s think what we want as an interface, and if ‘latch’ is the right name.

at the moment it changes nothing. In other gui (for instance else’s pic) latch off make the GUI send a bang on click, and if latch is on, it sends 1 on clickon and 0 on mouse up.

I’ve checked against SuperCollider and Max to see the default behaviour:

  • SC output one message all the time with a mouseon and mouseoff flag
  • Max outputs coordinates on click and move, but not on mouse up

Options for Pd:
1- I make it like max (no latch option, no output on mouseup)
2- we keep latch option, and decide here which behaviour is the right one

I’m tempted to do 1, as I cannot imagine a usecase for outputing the mouseup, except adding a message for that, which might break interface.

opinions welcome, especially of advanced pd users. feel free to ask elsewhere so we can mod it once and for all :slight_smile:

thanks!

5

Hi,
Option 1 would make sense, so both max & pd version behave the same.
Cheers!

1 Like
6

I’m tempted to keep the flag to ‘report’ mouseup. but maybe that changes nothing…

7

ok I found a few strange things as I was fixing this. I think the option will be called Mouse up with a box, so you get a ‘symbol mouseup’ on mouse up if it is ticked. Does that sound usable?

It gives the advantage to know if the person is super still yet pressing, or if the click/motion is done…

(also, what OS are you on? If Mac I can send you here prototypes, otherwise I’ll just push on the nightlies)

8

Pretty usable indeed.
I’m on linux.
The problem is the same for fluid.plotter by the way.

There’s another thing on pd / linux (maybe other os’) that I found a while ago,
flucoma-pd’s gui objects, if I update the gui objects ( for example, if I plot coordinates on a fluid.plotter ) while they are in a subpatch that is closed, I get pd’s console to complain in red, then every single pure data gui object stop working until I close the program.

I kind of forgot, since I’m rarely in this use case.

I will make a github report, to describe more precisely…

Cheers!

1 Like
9

indeed, I am correcting it at the same time :slight_smile:

I think there is already one - I have to investigate further - please check before you make a new one, and reproducing code is welcome.

I’ll implement the latch fix first, and will push, and see how my list of other fires goes :slight_smile:

1 Like
10

ok I pushed a corrected doc and external to the nightlies, let me know if that works out for you. so many little bugs found!