The Api Wishlist Thread

[joule]

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]

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.

[Raul (Raul (ulneiz))]

Here I have another important suggestion for controlling some complex window tools. It’s about being able to detect the movement of the mouse wheel. This, which is so obvious, is very strange that the API does not address it. It could be something like this:

wheel.up = boolean (true or false)
wheel.down = boolean (true or false)

This could perhaps enter in the key_handler (the mouse could function as a keyboard extension). Basically, only is necessary the ability to perform a function when the wheel goes up or the wheel goes down. In the end, we are only talking about 3 buttons and a wheel (up and down).

If you want to make it more sophisticated, it would also be appropriate to be able to differentiate the 3 mouse buttons, right, center and left, each with “pressed” and “released”.

If we address the entire control issue with an overview, we are only talking about 3 fundamental peripherals:

1. The alphanumeric USB keyboard. Currently, partially covered in the API.
2. USB mouse It is the most forgotten peripheral in the API (except for some objects that work automatically).
3. The USB MIDI controller. Covered.

The evolution of the API must necessarily cover 100% of these 3 peripherals.

…

I would also suggest to the moderator that this thread be anchored in the forum. It is very easy to lose it now. Danoise, are you here?

[Raul (Raul (ulneiz))]

@No-XS This feature is not for the API.

[No-XS]

Ok, I deleted it here. Not sure where to suggest it

[Raul (Raul (ulneiz))]

Here: https://forum.renoise.com/c/ideas-suggestions

[linq]

Just like @Raul, I’m also seeking a way of observing mouse scrollwheel activity (or laptop two-finger touchpad gestures) via the Renoise API.

I’m trying to create an instrument library tool that allows me to scroll through a list of instruments. Take a look at this video around 2:00 for an example–notice how quickly he scrolls through his instruments with a two-finger gesture. I want to do the same with a Renoise tool, but there’s no way of binding a callback function to the scrollwheel being activated.

One possible approach would be to add a mouse_handler_func argument to renoise.app():show_custom_prompt. For my use case, it would be important to at least give the option of capturing scrollwheel activity regardless of what is being hovered at the time; currently the mouse wheel only seems to get used if you’re actively hovering over a UI element that supports mouse wheel (like chooser).

It may sound silly, but even as a hard-core Renoise lover, I’m actually considering other DAWs because of this functionality not existing in Renoise. As a live performer, I need a fast way to browse through a large library of instruments. If I can hack something together in a tool that goes 80% of the way then I’ll be inclined to stick with that.

EDIT: To give a bit more context, I’m trying to use @danoise’s vLib library to scroll through a vTable which contains a list of instruments. But that UI element doesn’t appear to support scrolling via mouse wheel at this time (likely due to the limitation expressed here).

[Raul (Raul (ulneiz))]

Really offering compatibility for the mouse wheel should be easy to implement. In fact, there should be full compatibility from the API for the use of a standard mouse: Here is the base list of what you should implement:

1. Left button.
2. Right button.
3. Central button (wheel).
4. Up (wheel).
5. Down (wheel).

This only @taktik can implement it and he will know which will be the best way. The vast majority of mouses on the market have this “standard design”, as minimum.

Currently, the API only allows you to use the left button (and the rest of the buttons, right and center as if they were the left button.)

Only some specific objects defined in the API react differently to other mouse controls. This reminds me of the deficiencies of the xypad, which does not allow you to control the speed of the mouse pointer, making it useless.

Renoise seems to be very thought for keyboard commands, and is too abandoned for mouse control. Fortunately, in the API6 version for Renoise 3.2.0, it has greatly improved with the use of modifier commands with the mouse combination.

…

Speaking only for controls for touch screens. It is possible to generate 2 buttons that act as “press and hold”. In this way, you can navigate very easily up or down (or right or left), in any panel that has a list (track (horizontal), sequence (vertical), instrument (vertical) … or line (vertical)).

The only problem is the same as always: you need a floating window. Renoise does not offer an integrated panel so that programmers can easily enter into an integrated frame buttons and other API controls. I have always wanted a lower panel of fixed size, such as the track DSP panel, to be able to integrate API tools there. This would do all the work. Select the panel from the touch screen. A crosshead or something similar will appear. There you can easily scroll through the entire Renoise interface, at least the most basic navigation (track - sequence - instrument - line).

If @taktik made an effort to meet some demands of the programmers, we would achieve many things. Unfortunately, this software is a niche, and there really aren’t many tools programmers interested in Renoise. Probably for that reason, he does not receive the affection or the time necessary to implement all these things, which from a general point of view, are always secondary.

[joule]

I have a small, silly and specific request that would allow a TON of possibilities and GUI abusage.

renoise.Views.Button.transparent
-> [bool]

It would just make the button invisible, with the click mechanics intact.

With the possibilities of view:add_child et c, this would bring quite a lot of potential for custom/modified behaviors in, hopefully, well designed views. Kind of like an inversion of how the click-transparency of racks can be abused today…

[joule]

renoise.song().instruments[]:swap_phrases_at(index1, index2) seems to have a bit forgotten.

Currently, you have to do this manually by inserting a new buffer phrase and use renoise.InstrumentPhrase:copy_from() and :delete_phrase_at(). I’m stumbling upon this now. Not a biggie, but it will bang some observables and maybe it’s easy to add? Also, with this workaround you need to hook up all notifiers again, instead of how notifiers are nicely retained usually.

[Ledger]

A reload file from disk option in the right-click menu of the scripting editor, useful for when working with preferences xml’s

[cupcake]

A way to fire notes from the API without having to go down the OSC bypass and taking the third exit at preferences to port 8001.

Would be nice to pass MIDI captured with the script API on to Renoise also. But a method to fire a note like the OSC API’s “/note_on” “/note_off” & “/midi” would be just dandy.

[cupcake]

A bit more control over window properties for both the app and custom gui dialog windows such as focus setting/getting and position initialisation, saving, and restoring would be nice, thanks. Gets a bit boring that tool gui are always open in the centre of the app window, unless i’m missing something.

[Achenar]

Access to any instrument’s selected phrase. At the moment we only have access to this from the currently selected instrument. Same with an instrument’s selected sample.

[Achenar]

@Cas

Numba one (i probably mentioned more number ones but anyhow… just HTH)

• vb:sliders that can actually center a panorama/transpose/finetune at zero (hope this is clear… I mean just like in interface it’s kind of non-intuitive how the Center value has half bar filled… for in renoise of course it’s ok for me but would be really nice to have it for guis in tools. Also goes for :rotary)

Yup, just like the panning slider.

Edit: Centered rotary dials would be great too.

[dltfm]

@ffx

Please add: (_saving instead _save, to trigger just before song will be transformed into xml and saved to disk, the right moment to place custom data to the song, currently song comment only. Currently the trigger only seems to be available AFTER the song was saved AFAIK)

renoise.tool().app_saving_document_observable
-> [renoise.Document.Observable object]

Please, please, please implement this hook. Or allow custom data to be attached to each song. This would make so many things possible that are currently either impossible or super kludgy to implement.

Pretty please.

[taktik]

@dltfm

Allow custom data to be attached to each song

This indeed would be the cleanest solution for many other tools as well. I’ll see what I can do here, but unfortunately can’t promise anything.

Until then you also could, as a workaround, memorize the song’s state in the tool preferences, using the song’s abs path (renoise.song().file_name) as “key”. This of course binds the tool’s song state to the local tool preferences and thus can’t be transferred when moving or sharing a song, but this could be a wanted behaviour too.

[ffx]

Talking about easy modifications in the API: Is it possible that you also will connect the .fxp/.aupreset export to the api? Then I could add that to the midi export tool, so you would get all the presets automatically.

Also if the render-song dialogue had a “after-action-done-trigger”, you could add some actions like encoding m4as/mp3s, without rebuilding the whole damn render dialogue.

Thanks for consideration.

[toimp]

Its currently not possible to get the current cursor position in sample buffer:

I tried these, but it doesn’t work (only works with a selection):

renoise.song().selected_sample.sample_buffer.selection_start
renoise.song().selected_sample.sample_buffer.selection_end

Maybe something like this would help:

renoise.song().selected_sample.sample_buffer.cursor_position

Other topic about this:

SampleBuffer selection properties don't work how I expect it

When there is no current sample selection, the following properties don’t seem to behave how I would expect at all: renoise.song().instruments[].samples[].sample_buffer.selection_start renoise.song().instruments[].samples[].sample_buffer.selection_end renoise.song().instruments[].samples[].sample_buffer.selection_range[] I would expect that the selection range would be reported as { x, x } where x is the current cursor position. Instead they behave as though the entire sample is se…

[Ledger]

Addition of favorite/ short name name to loaded device properties:

Currently for plugin infos you can access:

[favorite_name]=> Driver
[is_bridged] => false
[is_favorite] => false
[name] => Native Instruments GmbH: Driver
[path] => Audio/Effects/VST/Driver
[short_name] => Driver

From a loaded device you can only get:

[name]=> VST: Native Instruments GmbH: Driver
[display_name]=> VST: Native Instruments GmbH: Driver
[device_path]=> Audio/Effects/VST/Driver

Would be great to have [short_name] at least for a loaded device. The main reason being that even though it is fairly simple to strip out the “/” or “:” to get the short name, I ran into a situation with the tool linked below, where cross platrorm you can have differences in name format. Just running into this again with a tool I’m working on and it creates some guessing + what seems like unneccesary extra formatting mess.

Audio Units seem to have the different formatting:

• AU differences explained

/////

Edit: although having short_name for loaded device would be great, there is also a bug with device_path:

Turns out to be not-a-bug, but leaving link as useful:

• bug-issue-with-device-properties

////