Small Bug in "Background Blend" values. Is value 51 omitted?

R3.1.0 x64 | W10 x64

This is a bit strange.According to the documentation (Renoise.Song.API.lua) to create tools with LUA:

renoise.song().tracks[].color_blend, _observable -> [number, 0-100]

The range value is from 0 to 100 (101 values).The problem is that the value 51 seems to be omitted (omited???).Then, from the value 51 to 99 it is an offset of 1 (a jump of 1: 52 = 51, 53 = 52… 99 = 98).Occurs on any type of track.

I think the correct range should be from 0 to 99 (100 values).Is it possible that there is some error here?

Perhaps the most correct thing is:renoise.song().tracks[].color_blend, _observable -> [number, 0-99] (without skipping any number)

For example:

If you use:

function color_blend( song, sti )
  song = renoise.song()
  sti = song.selected_track_index
  song.tracks[sti].color_blend = 55
end

Will return the value 54…Should return 55!

Edit :Will return the value 54 in Background Blend slider…Should return 55!

Just to clarify, I assume what you mean Raul (when you say ‘return’) is that this graphical slider and numerical value should be ranged from 0 to 100 with the numerical value displaying 3 digits (to accommodate the number 100) rather than just 2 digits. A thought: When you set color_blend to say 55 via lua, that numerical value could show a value of 54 because of how it is internally scaling the numerical 0-99 display?

Just to clarify, I assume what you mean Raul (when you say ‘return’) is that this graphical slider and numerical value:

attachicon.gifbb.png

should be ranged from 0 to 100 with the numerical value displaying 3 digits (to accommodate the number 100) rather than just 2 digits. A thought: When you set color_blend to say 55 via lua, that numerical value could show a value of 54 because of how it is internally scaling the numerical 0-99 display?

What I am indicating is that there is an error. In the graphical slider the correct range is 0 to 99 (100 values). If you use the slider, it works fine.I do not expect it to be changed to 1-100 (100 values).

What I am indicating is that from 0 to 50, the function withrenoise.song().tracks[].color_blendreturns the exact same value:

  • 0 return 0
  • 11 return 11
  • 50 return 50

But > 50 then:

  • 51 return 50 :wacko:
  • 52 return 51
  • 99 return 98

There is a jump of 1, from the value of 51, and higher. Here is an error.Scaling is 100 values, Renoise can not skip one.

From 0 to 100 there are 101 values, why?Maybe the programmer wanted to put a range of 1 to 100 in the slider, and stood half?I do not know, but as it is now, it does not seem right.

4Tey ^_^Apparently, the programmer wanted the slider not to exceed 2 digits (does 3 digits take up too much space on the slider?).Then, instead of removing the value 100 from the range, the programer have removed the value 51.This is a bit strange.It’s like program testing and then not leave quite finished.The simple thing would be to keep the range from 0 to 99 (100 values).

We can do tests using this function, executed with a button:

function color_blend( song, sti )
  song = renoise.song()
  sti = song.selected_track_index
  song.tracks[sti].color_blend = 55
  print ("color_blend: ", song.tracks[sti].color_blend )
end

And observe the terminal and the slider (Background Blend),observing what happens with the values, …48 ,49, 50 , 51 , 52…

Mysteries of Renoise! :o

Anyway, here’s a mistake…

From 0 to 100 there are 101 values, why?

Well another way of probably looking at that range Raul is that ol’ Taks was maybe thinking 0=off and values 1-100=color blend applied with 100=max color blend applied? So another way of possibly solving the display value issue might be to have the slider/numerical value display from 0-100 rather than 0-99? I agree Raul, that that slider/value is an inaccurate representation of the values that can be taken by color_blend, but I didn’t program Renoise and I’m sure Taks will get around to it sometime in the year 2489. Luckily this isn’t absolutely major red alert defcon 1 :smiley:

Just to add a little further Raul and your question ‘Is value 51 omitted?’…

Well let’s think about this, a couple of things to keep in mind. Firstly remember that in Lua a value of say 51 is represented internally as a floating point value and not a whole integer. So you can write:

renoise.song().tracks[1].color_blend = 51.999

Secondly, we know at that moment that the color_blend variable can range from 0 to 100. However the slider numerical value seems to scale from 0 to 99 (however you can slide the slider all the way to the right and it will latch the value 100, it’s just the numerical value will still read 99.) One way of looking at this is if someone asked me to take a value between 0 and 100 and scale the value so that it is now between 0 and 99 I’d probably multiply the value with 0.99 If we take a few numbers and do that:

12 * 0.99 = 11.88
32 * 0.99 = 31.68
50 * 0.99 = 49.5
51 * 0.99 = 50.49
74 * 0.99 = 73.26

Thing to notice here is that once the value goes > 50, the last two scaled digits fall below half. Well you could (as speculation) argue that that maybe goes some way of explaining why when you put a value > 50 into color_blend via lua, the numerical value display goes out by 1? Depends on how Renoise/Lua is internally rounding the floating point values Raul. ‘Is value 51 omitted?’ Well I’d say no (it wouldn’t make much sense for the programmer to isolate value 51 and remove it out of the number line :slight_smile: ), it is just how it looks via that numerical value which only shows the values between 0-99.

Just as a side note: Funnily enough a ‘floating point rounding thing’ can vary between Renoise os versions. For example if you write this in Windows 7 32-bit Renoise:

renoise.song().tracks[1].color_blend = 100.8

An exception is thrown because it probably has rounded the value internally up to 101. However writing the same thing with my Linux 64-bit version of Renoise produces no exception, possibly because it has ‘floored’ the value to 100? To imagine: Little things like this though with floating point in computing Raul can be the mathematical difference between defcon 2 and red alert defcon 1 :smiley:

Just to add a little further Raul and your question ‘Is value 51 omitted?’…

Well let’s think about this, a couple of things to keep in mind. Firstly remember that in Lua a value of say 51 is represented internally as a floating point value and not a whole integer. So you can write:

renoise.song().tracks[1].color_blend = 51.999

Secondly, we know at that moment that the color_blend variable can range from 0 to 100. However the slider numerical value seems to scale from 0 to 99 (however you can slide the slider all the way to the right and it will latch the value 100, it’s just the numerical value will still read 99.) One way of looking at this is if someone asked me to take a value between 0 and 100 and scale the value so that it is now between 0 and 99 I’d probably multiply the value with 0.99 If we take a few numbers and do that:

12 * 0.99 = 11.88
32 * 0.99 = 31.68
50 * 0.99 = 49.5
51 * 0.99 = 50.49
74 * 0.99 = 73.26

Thing to notice here is that once the value goes > 50, the last two scaled digits fall below half. Well you could (as speculation) argue that that maybe goes some way of explaining why when you put a value > 50 into color_blend via lua, the numerical value display goes out by 1? Depends on how Renoise/Lua is internally rounding the floating point values Raul. ‘Is value 51 omitted?’ Well I’d say no (it wouldn’t make much sense for the programmer to isolate value 51 and remove it out of the number line :slight_smile: ), it is just how it looks via that numerical value which only shows the values between 0-99.

Just as a side note: Funnily enough a ‘floating point rounding thing’ can vary between Renoise os versions. For example if you write this in Windows 7 32-bit Renoise:

renoise.song().tracks[1].color_blend = 100.8

An exception is thrown because it probably has rounded the value internally up to 101. However writing the same thing with my Linux 64-bit version of Renoise produces no exception, possibly because it has ‘floored’ the value to 100? To imagine: Little things like this though with floating point in computing Raul can be the mathematical difference between defcon 2 and red alert defcon 1 :smiley:

This is very interesting and makes sense.If the cause is to take a multiplier of 0.99, this method causes an error (number jump).Would not it be easier to use a range from 0 to 99, because it is simpler?

If we choose to use a valuebox with a range of 0-99, is possible to use a correcting conditioner ( if a > 50 then a = a + 1 end ) so that the color_blend value matches the slider.I have solved it this way in my tool:

--------------------------------------------------------------------------------
-- REARM BACKGROUND BLEND (COLOR BLEND)
--------------------------------------------------------------------------------
--Rearm color blend --song.tracks[].members[] --song.tracks[].group_parent
function pest_fn_rearm_cblend( song, a, b, c, d, e )
  song = renoise.song()
  a = vb.views['PEST_VB_CBLEND_TRACK'].value
  b = vb.views['PEST_VB_CBLEND_SGROUP'].value
  c = vb.views['PEST_VB_CBLEND_GROUP'].value

  --correctors for color_blend >50. In background color slider, if color_blend < 51 then a = a. If color_blend > 50 then a = a + 1
  if ( a > 50 ) then a = a + 1 end
  if ( b > 50 ) then b = b + 1 end
  if ( c > 50 ) then c = c + 1 end
  
  for i = #song.tracks, 1, -1 do
  d = song.tracks[i]
  e = renoise.Track
    if ( d.type == e.TRACK_TYPE_SEQUENCER or d.type == e.TRACK_TYPE_SEND ) then
      d.color_blend = a
    elseif ( d.type == e.TRACK_TYPE_GROUP ) then
      if not d.group_parent then --if selected track does not have group_parent
        d.color_blend = c
        else --if selected track have group_parent
        d.color_blend = b
      end
    elseif ( d.type == e.TRACK_TYPE_MASTER ) then
      d.color_blend = c
    end
  end 
end

PEST_VB_CBLEND_TRACK = vb:row { vb:text { text = ' Tr', height = 22 },
  vb:valuebox { id = 'PEST_VB_CBLEND_TRACK', width = 50, height = 22, min = 0, max = 99, value = 15,
  notifier = function() if vb.views['PEST_CB_RTIME'].value == true then pest_fn_rearm_cblend() end end, tooltip = 'Value of background blend to tracks & sends.\n[Default value = 15]' }
}
PEST_VB_CBLEND_SGROUP = vb:row { vb:text { text = ' SGr', height = 22 },
  vb:valuebox { id = 'PEST_VB_CBLEND_SGROUP', width = 50, height = 22, min = 0, max = 99, value = 30,
  notifier = function() if vb.views['PEST_CB_RTIME'].value == true then pest_fn_rearm_cblend() end end, tooltip = 'Value of background blend to subgroups.\n[Default value = 30]' }
}
PEST_VB_CBLEND_GROUP = vb:row { vb:text { text = ' Gr', height = 22 },
  vb:valuebox { id = 'PEST_VB_CBLEND_GROUP', width = 50, height = 22, min = 0, max = 99, value = 55,
  notifier = function() if vb.views['PEST_CB_RTIME'].value == true then pest_fn_rearm_cblend() end end, tooltip = 'Value of background blend to groups (parents) & master.\n[Default value = 55]' }
}
PEST_BT_CBLEND = vb:button { id = 'PEST_BT_CBLEND', width = 49, height = 22, text = 'Blend', color = { 0x00,0x40,0x70 },
  notifier = function() pest_fn_rearm_cblend() end, tooltip = 'Rearm the background blend to all tracks.'
}

PEST_CB_RTIME = vb:row {
  vb:text { text = ' RT', height = 22 },
  vb:vertical_aligner { mode = 'distribute',
    vb:checkbox { id = 'PEST_CB_RTIME', value = false, 
      notifier = function()
        if vb.views['PEST_CB_RTIME'].value == true then
          vb.views['PEST_BT_CBLEND'].color = { 0x40,0x00,0x00 } vb.views['PEST_BT_CBLEND'].active = false
          else
          vb.views['PEST_BT_CBLEND'].color = { 0x00,0x40,0x70 } vb.views['PEST_BT_CBLEND'].active = true
        end
      end,
      tooltip = 'Rearm in real time the background blend to type of track.\nTr = tracks & sends.\nSGr = subgroups.\nGr = groups (parents) & master.'
    }
  }
}

Adding this patch:

--correctors for color_blend >50. In background color slider, if color_blend < 51 then a = a. If color_blend > 50 then a = a + 1
  if a > 50 then a = a + 1 end
  if b > 50 then b = b + 1 end
  if c > 50 then c = c + 1 end

Out of curiosity:

renoise.song().instruments[].midi_output_properties.delay, _observable

-> [number, 0-100]

– Macro value.

renoise.song().instruments[].macros[].value, _observable

-> [number, 0-1]

Macro value string (0-100).

renoise.song().instruments[].macros[].value_string, _observable

-> [string]

It does not appear that there are many properties that use a range of 101 values.This is how little I found in the documentation.

Fair enough Raul, pop some ‘if’ clause(s) in, but I suppose with that idea above what happens if the user wants the value 76 in color_blend? You add 1 and store the value 77. The user would have to input 75? So with that solution you’ve missed a number basically anything > 50 just to ‘compensate’ (isn’t really a big problem though…)

But just as a personal preference/opinion of mine Raul… What I’d do is just have a text value box that accepts values from min=0 to max=100 and fill the value the user gives directly into color_blend. Personally it wouldn’t really bother me that it would be ‘1 out’ on values > 50 with that (seemingly scaled) numeric display value from Renoise :slight_smile:

If you use a range from 0 to 100, the user has access to the value 100, and the value 100 does not exist in the slider for background color.As I have resolved in my tool, if you select 75 in the valuebox, will return the value 75 in the slider.Thus there is no way to confuse the user.The problem I had before is that with the range 0 to 99 for the valuebox, a value >50 did not return the same value in the slider, with 99 in valuebox return 98 in the slider.

Well, at least I’ve been able to avoid it. :slight_smile:

All I’m saying is Raul is in this instance I personally wouldn’t program around it to ‘sync’ the value between what the user types in in your text box to what the user sees with the Renoise value on that dialog. But if you ‘don’t want to confuse the user with 1 off’ then fair enough.

Interestingly (I don’t know if you have tried this one Raul) I find (this under Linux btw, don’t know if the same thing happens under Windows) if you go to that background blend dialog value box and type say the value 94 in. Then I go to a terminal and ask lua what the value is with say:

print(renoise.song().tracks[1].color_blend)

Check! I get back the value 94. I try the value 98 in that dialog value box. Check, lua reads back 98. Lovely :slight_smile: Now I try typing the number 99 in that value box and then ask lua to read the set value back. I get 100. To get the value 99 I have to type say 98.9 in that box to get 99 back from lua. Ah, it is like a little computer game in itself Raul :slight_smile:

[Edit:] But just to clarify what I think the small bug/overlook here is. The numerical text value box next to the slider should be set to min=0 max=100 rather than min=0 max=99. So you can do:

Attachment 7431 not found.

and then that should correspond with the value you set via lua.