Support

If you have a problem or need to report a bug please email : support@dsprobotics.com

There are 3 sections to this support area:

DOWNLOADS: access to product manuals, support files and drivers

HELP & INFORMATION: tutorials and example files for learning or finding pre-made modules for your projects

USER FORUMS: meet with other users and exchange ideas, you can also get help and assistance here

Line Editor

Post any examples or modules that you want to share here

Re: Line Editor

Postby Father » Wed Nov 12, 2014 9:37 pm

TheOm wrote:It works like it should here. It loads the correct state even if the editor hasn't been opened. I can only test for Fuity exports though.

Confirmed. FL version works fine. :!:
So whats the cause?
Father
 
Posts: 204
Joined: Thu Jan 09, 2014 5:48 pm

Re: Line Editor

Postby nix » Thu Nov 13, 2014 9:49 am

can an 'after load' trigger be introduced somewhere to mitigate?
User avatar
nix
 
Posts: 759
Joined: Tue Jul 13, 2010 10:51 am

Re: Line Editor

Postby Father » Tue Nov 18, 2014 4:01 pm

nix wrote:can an 'after load' trigger be introduced somewhere to mitigate?

That after load wasn't always working. I think it had something to do with ruby initializing before receiving the input data, seems to be fixed in the 3.0.6 update.
Last edited by Father on Sun Dec 21, 2014 8:40 pm, edited 2 times in total.
Father
 
Posts: 204
Joined: Thu Jan 09, 2014 5:48 pm

Re: Line Editor

Postby Antimac » Fri Nov 21, 2014 9:47 pm

Many thanks for sharing this TheOm! This is truly awesome!
Antimac
 
Posts: 3
Joined: Fri Nov 21, 2014 3:00 pm

Re: Line Editor

Postby Father » Sun Dec 21, 2014 8:31 pm

TheOm wrote:It works like it should here. It loads the correct state even if the editor hasn't been opened. I can only test for Fuity exports though.

I'm not sure but it seems to be working in 3.0.6 version.
Father
 
Posts: 204
Joined: Thu Jan 09, 2014 5:48 pm

Re: Line Editor

Postby TheOm » Mon Dec 22, 2014 2:29 am

Father wrote:I'm not sure but it seems to be working in 3.0.6 version.

Nope, it loads a wrong state sometimes but I just can't figure out how to fix it.
TheOm
 
Posts: 127
Joined: Tue Jan 28, 2014 7:35 pm
Location: Germany

Re: Line Editor

Postby Perfect Human Interface » Mon Dec 22, 2014 3:28 am

This in an unhelpful post but Ruby seems to be prone to screwing things up on load in general. I recently had to remove all instances of a ruby block (it was one short line with an input and an output) from a schematic and replace it with green because the schematic wouldn't load saved values correctly with it.
Perfect Human Interface
 
Posts: 663
Joined: Sun Mar 10, 2013 7:32 pm

Re: Line Editor

Postby tulamide » Tue Dec 23, 2014 1:42 am

TheOm wrote:
Father wrote:I'm not sure but it seems to be working in 3.0.6 version.

Nope, it loads a wrong state sometimes but I just can't figure out how to fix it.

Since the ruby edit instance uses "def event", it probably won't be solved with 3.0.7, so here's a proposal. Maybe it helps, if you forego ruby values and sending them. Instead you could use global variables. That doesn't solve the problem of the order (declarations first, best done on top layer as first inserted object), but you can at least eliminate the ruby value construct as a possible source of issues.

Edit: Made a quick schematic of what I mean.
Attachments
RubyValue_Replacement.fsm
(464 Bytes) Downloaded 471 times
tulamide
 
Posts: 1931
Joined: Sat Jun 21, 2014 2:48 pm
Location: Germany

Re: Line Editor

Postby MyCo » Sat Jan 10, 2015 8:09 am

OK, I don't fully understand the code... But:

    1. never EVER call getViewSize in init, as it is called before views are initialized
    2. When you have a calculation for graphic stuff, call it from draw. When you want to force a recalculation, set a status value to nil and call "redraw". This'll call draw and implicitly force a recalculation (that has to check the status value and only execute when nil, set the status value to something when it's done)
    3. never rely on input values (and their type). There is an issue at the moment (probably not worth fixing, cause it would mess up existing code).

regarding point 3:
This is a quite important one. It causes a lot of ruby exceptions on first load. Connectors might startup unitialized. When you have an input "foobar", make sure it get's checked first before you do something with it. eg:
Code: Select all
return unless @foobar.is_a?(...)

or a bit more unsafe:
Code: Select all
return if @foobar.is_nil?

or assign it to an internal value with a forced default. eg. for a Numeric:
Code: Select all
@myFoobar = @foobar||0


My 2 cents... @Father, hope that helps :twisted:
User avatar
MyCo
 
Posts: 764
Joined: Tue Jul 13, 2010 12:33 pm
Location: Germany

Re: Line Editor

Postby Father » Sat May 30, 2015 10:26 pm

Thanks MyCo.
I used static values instead of calling getViewSize not only in int, but the whole code, it wasn't the case. I think it draws before receiving the preset array. Because adding a delayed after load trigger, sometimes makes it work. like this:
afterload.jpg
afterload.jpg (29.7 KiB) Viewed 16913 times

of course this is not a solution, it fails with different schematics. Is there a way to make sure the input data is received before first initialization of the ruby code? or something like that...
Father
 
Posts: 204
Joined: Thu Jan 09, 2014 5:48 pm

PreviousNext

Return to User Examples

Who is online

Users browsing this forum: No registered users and 6 guests

cron