W11. Two bugs?

[whyterabbyt]

Waveform Version 11.0.26 (Built: 8 April 2020) (64-bit) on Win7 x64.

1) Binding alt-/ shows as bound to / It seems to be the only key this happens for

2) The following macro, from 'Inventive Creation' video series on youtube only works as an Action, not as a bound key.

Code: Select all

Tracktion.setPosition ('transport', Tracktion.getPosition ('markOut'));
Tracktion.splitClips();
Tracktion.setPosition ('transport', Tracktion.getPosition ('markIn'));
Tracktion.splitClips();

Its function is basically to turn a selected Range into a Clip, a bit like 'Separate' in ProTools. Even if I break it up, neither of the two setPosition/splitClips parts work properly.

When the macro is run as an Action it works fine, but when run from a key combination, it basically splits at the edit cursor not the Range points.
That seems to be because I have 'Use the edit cursor for editing operations' enabled. If I disable it, the key-bound version works like the Action-bound version.

Other operation using the Range position work fine eg setting the in/out markers

Code: Select all

Tracktion.setPosition ('loopIn', Tracktion.getPosition ('markIn'))

[whyterabbyt]

Anyone?

[fde101]

The macro API is somewhat anemic and from what I can tell I don't think there is currently a way to get around #2. I don't think it is a bug, but rather a suboptimal consequence of the way they designed things.

[dRowAudio]

What do you mean by "anemic"?

Yes, the problem with having "Use the edit cursor for editing operations" means the "splitClips" function will pick up the current cursor position. If you move the mouse out of the arrange window it should work as expected.

I think what we really need to do is add an API function to split at a specific time. I'll add that the FR list we have but I'm deep in Rack refactoring to fix PDC at the moment.

[fde101]

What do you mean by "anemic"?

Weak.

I find it very limiting. Rather than exposing a usefully complete document model it is more like a collection of functions that seem to have very large and seemingly arbitrary gaps.

Don't get me wrong, *some* very powerful macros are possible right now... but other macros that seemingly should be much simpler seem to be very difficult if not impossible to put together.


Instead of having one big global object with lots and lots of scattered functions associated with it, I think you really should have designed the API around various types of objects ("Track", "Event", "Plugin", "AudioInput", "Marker", etc.) and provided the relevant functions for each type of object. For one thing, that would have made it easier to spot where the functionality gaps are...

[dRowAudio]

I agree, but, building an API like that takes a long time and severely limits us to making changes.
Having a higher level API like we have which enables you to build up custom functionality is quicker and gives us more flexibility to change things under the hood.

Technically though you can get at the underlying objects and make changes to them. The "Edit Element Interaction" sub menu gives you low-level access to the underlying juce::ValueTree (basically XML) objects which you can then get/set any property on. The problem with this level is that it involves looking at the underlying XML storage or Tracktion Engine code base to determine what properties you can set and their values. A slightly better level abstraction would be similar to an HTML DOM that had a bit more restriction on the values that could be used and could enable introspection of the available properties etc.

The problem is time. I've got thousands of people all asking for completely different features and I just can't think through all the problems and come up with and then maintain the optimum solution for them in short spaces of time. I have to prioritise what to work on and at the moment that's fixing PDC in the audio engine I'm afraid.

The reality is that the current API is useful for the large majority of people and it's difficult to justify spending huge amounts of time making it more useful for a small amount of people.
Don't get me wrong though, there is on-going work in this area and as more and more internal functionality moves to this Javascript layer the API will grow. It probably needs some other feature to boost its priority to the next level though such as an overhaul of MIDI controller input and making actions assignable to those etc.