6 OP FM synth: Opening Help kills plugdata

[muziker]

Using plugdata on the develop branch, git describe is v0.8.0-766-g23daa5a6a, selecting help while using the 6 Op FM synth kills plugdata. Haven't checked if opening help file for other objects will do this too.

Also, there's a bunch of Filesystem_x.zip files in the Resources folder, and a Documentation.bin file. Is this needed ?

[dromer]

You already reported this here: #1510

[adventurecomputer]

No that's different. In this case, if you were to place an 6OP synth on the canvas and click help, plugdata get's killed. At least for my setup. The other is the pitch inlet takes in a number, but the user does not know what range is valid, so a relatively low number, assuming it is hz, causes the entire gui to hang. I've made my guis hang before in this way. Usually it is a graphical element somewhere trying to write to the gui at some high speed.

[dromer]

Please try one of the nightly builds because as I mentioned in the other ticket there have been countless changes since the version that you are using.

https://plugdata.org/download.html

git describe is not a good command to reference for versioning.

[timothyschoen]

It's weird that git describe still says 0.8.0 though. Is this something I'm doing wrong?

I think I've had crashes myself with the 6 Operator FM synth too in the past. I'm unable to reproduce the crash when opening the helpfile on the latest nightly though, what OS are you on?

[timothyschoen]

No that's different. In this case, if you were to place an 6OP synth on the canvas and click help, plugdata get's killed. At least for my setup. The other is the pitch inlet takes in a number, but the user does not know what range is valid, so a relatively low number, assuming it is hz, causes the entire gui to hang. I've made my guis hang before in this way. Usually it is a graphical element somewhere trying to write to the gui at some high speed.

I think the GUI for this patch is kinda slow in general, slower than I would expect. You can feel the framerate drop slightly when scrolling, which shouldn't happen for such a simple patch. I'll look into that too, I suspect it's related to your GUI freezes.

[muziker]

well I'm on linux. There's 2 ways to do tags. The first is a lightweight tag and the other is the annotated one. git tag -a -m . git describe is going to go for the annotated tag. So there's a discrepancy if you used a lightweight tag vs an annotated one. Personally there should have only ever been annotated tags, but supposedly the idea is you could have tagson the local branch and not push them into the origin.

[dromer]

The only tags that are (currently) used are the regular/minimal ones.
So lets not rely on git describe for version information :)

If you are building from source a git rev-parse HEAD is more reliable to point to a specific commit.

[muziker]

If doing "git describe" the output will be the nearest annotated tag + g + string of the hash; an abbreviated version of git rev-parse HEAD. It's unlikely to have a hash collision, so git describe is probably good enough. Or "git log -l --format=%h" as used in the CMake files.

[dromer]

It's not "good enough" when we can't tell what commit you are on and if the describe command only causes confusion as it does now.