Typospread binsize bug

Hello devvvvs, I have just come across a really strange bug in the Typospread (Spreads) node.

If i pass a string to a Typospread, which has spaces or linebreaks in it, the binsize pin shows the correct values - the sum of all binsizes is equal to the spreadcount as expected. If I add or remove a linebreak or space in the input string, the binsize goes up by a lot, even though the number of slices in the x and y output doesn’t. If the patch is reloaded the value goes back to the expected value and changes again once a space or linebreak is added or removed.

I have attached a patch showing the bug. Switch between the different input strings, which all contain the same number of characters but different numbers of spaces or linebreaks. If you switch to an input string which shows a wrong binsize sum, save and reopen the patch it will show the correct value. Even more strange, switching between the input strings and going back to the string, which was connected when opening (ie. showing the correct value), it will also show a wrong value.

Anybody know of a fix for this problem, I am relying on the binsize pin for a project i’m working on.

I am using 30.2 x64.

Thanks.

typospread_bin_bug.v4p (9.2 kB)

Really, nobody has anything about this bug?

Come on devvvvs, please acknowledge the bug so I can abandon this project early on till the bug is fixed or a suitable workaround is found. As it stands I have no solution to this problem. The binsize pin needs to be correct, even after the input string has changed and needs to be able to include spaces and linebreaks, which of course should have a binsize of 0, because they don’t consist of any points.

An easy workaround seems unlikely, as its quite unpredictable and even the wrong results are not consistent, but change back to “normal” after reloading the patch.

yes, looks like a bug

Just noticed the TypoSpreads help file actually shows the bug, but somewhat hides it a little bit to add to the confusion.

If you expand the IOBox next to “< points per character” to show all 6 lines, you can see that

a) the number shown is not points per character at all, but the number of the first character and all others have different amounts of points, which simply add up to the spreadcount. By that logic there should be 265 (53x5) slices and not 277

b) that the space at the front of the sample string has a binsize of 53 and the E at the end a binsize of 0.

Adding another space to the string in the example causes red nodes in Ord2Enum and therefore the Point node, further illustrating the bug.

I have attached the help file with only the IOBox expanded to show all values.

TypoSpread (Spreads) help.v4p (12.8 kB)

In case it helps, the binsize pin in the TypoSpread node was introduced with vvvv45beta26.

Still nothing on this? Devvvvs where are you??

next alpha should show the fix. please check. thanks for your report and patience!

Thank you @gregsn, I have just played around with it a little bit and it seems to work as expected in the latest alpha.

May I suggest to also update the help patch in the way of expanding the IOBox connected to the bin size pin, to show that it is “points per character”, but each character has a different number of points. Also I would move the space to the middle somewhere, to make it more obvious - at first I didn’t even notice it was there. See the attached help patch.

Now I can finally get back to making vvvv paint with type and teach it how to do pencil drawings ;)

TypoSpread (Spreads) help.v4p (12.8 kB)