The Api Wishlist Thread


(taktik) #261

A single, multiple or all columns at once, note and/or effect columns can be changed within one single operation and thus will result into one notifier call too. That’s why the notifier can’t provide that info.

I see where this suggestion comes from though. You need this for this tool here, don’t you? New Tool (3.1): FormulaOne

Then you’d actually need a different kind of notifier: One that only fires, when the user directly enters or records a new note or effect column value. Right now the notifier will also be called when cut/copy pasting, doing something in the advanced edit, on undo and redo and when other tools write into the pattern. Those are all scenarios where you don’t want to apply your formulas. If you do, you’ll actually will start breaking those other changes.


(joule) #262

Thanks for valid points. I see the problem. Maybe user_edited = bool in the event table would be helpful, if possible and not too specific of a request. It would probably be hepful to narrow it down well enough.

Even more luxurious would be something like edit_type = user / user-pasted / offline / advedit

(Yes… tool seems to work fine, but the main “problem” is that the user could get confused by formulas where column_index is used, which is just being generated by an “educated guess”. The tool re-rendering tracks isn’t much of a problem - but kind of desired. About not affecting adv edits, I guess the user has to ‘take some responsibility’ regarding what formulas are active.)

EDIT:
Your suggestion about a user-edit_line_notifier is also good, and maybe simpler. It would be very handy and fit like a glove in this case. I guess it should bang on cut/paste operations as well (?).


(joule) #263

The subject might have been touched before, but this is a more concrete suggestion…

I always thought it prudent if renoise.Views.View was inheritable. I don’t know if it’s possible/easy to achieve though. It would allow vLib or any other custom pseudo-views to be made in a way that is syntactically treated the same way normal Viewbuilder classes are.

Like so:

class 'MySlider' (renoise.Views.View)

function MySlider:__init(args)
  renoise.Views.View.__init(self)
  
  self.slider = args.vb:slider { }
  self.value_text = args.vb:text { }

  self:add_child(
    args.vb:row {
      self.slider,
      self.value_text      
    }
  )
  
  self._value = renoise.Document.ObservableNumber()
  
  self.value = property(
  -- updating whatever mechanics
  )

end

Note: It also implies that the user has extended renoise.Viewbuilder with the appropriate method passing the vb object, which is already possible.