Question regarding Reaper compatibility ? about boops

[sjaehn]

2. Boolean atom with a size of 1 is fixed in 18ebf50

[sjaehn]

3. state:freePath() is now used too in 219c855

[mikobuntu]

@sjaehn @justinfrankel I can confirm that B.Oops is working on all tracks now, with my initial tests ( so far ) with both the latest dev version of Reaper and this git repo. You guys may have to sort out the technical details tho. thanks both of you

[sjaehn]

Wow, nice to know about the plugins are already doing something in Reaper. I know that they are almost at the beginning.

Is it right that B.Slizr works correctly, but B.Choppr didn't? This is interesting as B.Choppr is based on B.Slizr. Plus additional features. If you can confirm it then it's a starting point.

I know that some of my plugins are a bit special as they require a stereo audio input plus a control port for midi and/or time/position.

I'll just look to irc#lad

[mikobuntu]

Yes your plugins will be even more widely used now I guess :)

You are correct that B.Slizr does work correctly, while B.Choppr doesn't. I actually thought that one was just a newer version as they look and act so alike.

You can follow the thread here https://forum.cockos.com/showthread.php?p=2399573#post2399573 and also check for new updates in the Reaper pre release discussion part of the forums

[sjaehn]

Thanks for the link. Indeed, B.Choppr is the successor of B.Slizr. And it's based on a 1.2.x version of B.Slizr.

[mikobuntu]

Actually scrub my last post, somehow I forgot to actually pull down some sliders on B.Choppr in my last test. and it is now working correctly on a normal track in Reaper [ sorry about my mistake in testing ]
I think tho that the last update ( within the last hour ) may have fixed something, but I still only have the issue with BOops now

[sjaehn]

Yes, Justin mentioned some points to take in account. The sequencer pattern and the shapes (scratch, wah) are stored in the turtle syntax as this would produce thousands of extra code lines in the ttl files. But there is a way to inform the host about changes - if supported: #10 (TODO)

[mikobuntu]

Great find sjaehn, hopefully you will get this working. Thanks for your time on investigating this issue :)

[justinfrankel]

Hi, cool plug-ins! A few things I've noticed (we've been improving support to the best extent possible, adding additional turtle capabilities to support presets etc too):

1. The biggest issue seems to be behaviors of the worker scheduling feature that B.Oops depends on. For one -- if the scheduler runs the worker immediately (e.g. as it would do for offline rendering), then incorrect results seem to be produced. The other issue is that we were likely not handling the call of additional scheduling from the scheduling reply function correctly, which we'll fix.

2. (minor) a boolean atom with a size of 1 is passed to state_save(), perhaps that should be size 4?

3. when calling abstract_path() and absolute_path(), you should use our provided free function rather than free() (or leaking) ;)

[sjaehn]

Thanks for your response @justinfrankel .

1. It's a tricky part and this will take some time.
2. Thanks to mention. This is a bug in the plugin. size_of (bool) is (in the most cases) 1. Whereas LV2_Atom_Bool is the same as LV2_Atom_Int and picks up four bytes. Will be fixed.
3. Will be fixed as well.

[sjaehn]

1. I had the idea that this issue might be related to the fact that the host is not informed about changed state data (pattern, sample file path, shapes, linked piano keys). This is now fixed by supporting state:Changed in 5f2affd . However, I'm in doubt if this already fixes the problems the problems mentioned.

[mikobuntu]

Building BOops now, I will test regarding my initial issue, but @justinfrankel will have to chime in regarding the more technical details. Thanks @sjaehn , much appreciated for your time working on this.

[sjaehn]

1. db|reap (thanks) reported a scheduling order issue on irc#lad. Fixed in fc05b7c .