Tracktion alternatives?

[Trancit]

It will be a pleasure for me to test them

[HansP]

I have been using T1 since the GS invitation, then tried T4 but continued T1,
now T5 and shortly after, T6.

Got quite something to tell and ask, but will try a different thread later for a different viewpoint.


My point would be a professional outlook in strategy, it will touch options of growth.
In short, the sequence of versions for me does not lead to a recommendation, but perhaps it can be fixed with a limited effort and aspect on strategy.
We are getting old here. Young users have little patience, but do want get things done.

My viewpoint is that free versions must show a type of progress, that will justify to buy a commercial version.


T1 was very very promising, especially as the Cubase thing totally rubs me the wrong way. A friend has that, and every other minute to me it's a huge WTF. So, T1 was for me.

T4 had glitches in the free registration. Improvements to me did not look important. Graphics did not look good, though it was a must, to leave the older engine that wasn't good for Windows newer than XP.

T5 was a huge leap. The audio engine sounds better. Plugin testing and integration was improved. Freezepoints. Automation a lot better. Folder tracks. Better graphics and colors. Better project and settings management.
I started to use it.
But there were a lot of glitches, and crashes, Win7 Pro here with 4GB Ram, using 32bit Tracktion.
Some free plugins were crashing the graphics engine (by moving sliders while playing sound, the handlers of sound and graphics conflicted each other and the sound buffer went into an endless loop).
Other plugins crash the data space. This should never be possible. Probably loose parameter buffer checks.

T6 seemed to improve the graphics engine once more. A certain type of plugin crash with graphics is gone.
There are still other crashes. When memory is low (open browser), it can crash without warning.
The latest issue is with racks. I make complex use of racks in the mastering section. Suddenly, rack parameters for the particular plugins do not load with reopening the edit, but it loads only default values.
I found out that it has to do with the version switch. A project that was started with T5 does not show this crucial error. It depends on having synced *.trkedit and *.tracktionedit files.

Effect return tracks (using the aux sends) that hold plugins with latency, seem to have no correction for this latency. With a WAV track, at least I can shift it for some milliseconds. But the latency input field of T1 seems gone. A complex rack might require manual latency correction (as a global, and by particular plugin and "wire").


Facit
The evolution of bugs and repair does not really make me believe that Waveform has repaired the bugs that are crucial to me.
Actually, a free version should be even more bug-free than the developing version branch that has more features, so we know what we will have when we pay, and can show some limited patience.
I believe that if T6 gets a makeover that fixes most bugs, then many more professional engineers with a good budget might jump on the Tracktion bandwagon. This means, charging for good and fast support can boost the whole product and process.

Open Toolbox scene and crowd:
This is about meta-level of all those XML files.
With some technical documentation, folks can write and share a myriad of macros and meta-tools.
One would be a mix documentation of every structure, plugin, and setting. (like a MS-Access database documentor, that can be written by anyone.)
Folks would create a library of plugin-meta data, with hundreds of plugins, to document which byte in the data is connected to which knob, and how the values translate from hex to graphic display. (like it's about MIDI exclusive data for a synthesizer, I did that for a DX7 bank documenter.)
And subito after that, a mix-compare documentor. It would say, between these two edits you have inserted 4 plugins, and changed the following parameters etc etc.
Another one would rename the plugins.
Another one would allow to change the sort order, and do an automated but user-defined (re-)sorting of racks and presets.
Another one would let you click a number of automation curves, and move them by nn.nnn seconds.
Another one would let you change every directory path in a project and edit, and keep all those IDs together.

How to do that:
Somewhat improved _bureaucracy_, to track the type and severity of bugs in the Tracktion version chain, using a matrix about the software environment of the users (e.g. Win7, or Android; mostly free plugins, or highpriced stuff coexisting because of Pro-Tools or something; error type: data and structures, audio, graphics + user interface, workflow problems), and giving reference to the alleged segment of the code that is perhaps the culprit. Fill in a lot of info there, after fixing a bug. This give a greater picture about the situation.
Find out at what point in the development the error occurred (e.g. already from the start T1), and if it is possible to use the code correction in T6 _and_ newest Waveform with not too much overhead and rechecking everything.
Don't make a MS mess with the code. Make regression easy, invest in this, because of the basic paradigm, with all the cross-compiling, and object-oriented workflow.

Make documentations for 3rd party programmers, who want to deal with the xml data. Make a toolbox button, that saves the edit, opens a meta tool from a list, let you do something with that, and then checks the changed xml for errors, and reloads the edit.


These are some humble ideas.
I hope I will find time to give more detailed reviews in a new thread.

[dRowAudio]

Hi HansP, thanks for the suggestions.

We do take bug fixing very seriously and obviously take time to fix them, however, the free versions are offered without support or continued maintenance. This is the only feasible way of making those versions free as we need to dedicate resources to paying customers.


I'm not really sure what you're trying to propose with the "Open Toolbox"? The plugin state data is simply a binary blog of data the plugin gives us when we save and we send it back to the plugin upon loading. We just happen to save that as a base-64 encoded string in our Edit files. There's an infinite amount of ways a plugin could internally use this binary blob so it's not really feasible for us to invest time in trying to decode them...

Similarly, I like the idea of having an Edit comparator but again this would simply be too complex for us to develop and maintain and the uses fairly small. If you really want to, I suggest using a tool such as diff or macOS's FileMerge to show differences in the XML.
As for some of the editing operations, we have a great editor for that, it's called Tracktion/Waveform!

Although we use XML as the storage format for our Edit files, that's really just for simplicity and helps us when developing/debugging. We do reserve the right to change the structure from time to time if it makes sense. We have done this in the past and it's one of the reasons we don't support backwards compatibility. Opening this up further by officially supporting 3rd party editors and documentation etc. would make this impossible.


Although we use KVR for user-based support, remember that we do also offer direct email support via our ticketing system and internally we have a bug tracker that we use. The reason we don't open that up to everyone is that we need to verify bugs before entering them and then they need to go through our testing procedure before they get cleared. If it was possible for everyone to access and modify this database things would rapidly spiral out of control.

We are in the process of improving the release/testing process of our software for upcoming releases which should help us catch things early. We're still ironing out the details but stay tuned for more information when we have it.

All the best and thanks for your comments.

[HansP]

dRowAudio and Tracktion people, thanks a lot for reading and thinking about.

I see you have your full-fledged enterprise culture, these matters are not foreign to me.
Still, I am stating a selfish opinion, but try to compensate with some bug details (upcoming) and general ideas.

When it's about maintenance, you are getting close to operating system vendors, because eventually you want to see your product as mission critic to your clients, in a way that they rely on it, but also can have their own pace of infrastructure, as their enterprise is needing.
People are also lagging with 2 Windows version numbers, and people paid for Tracktion 6, isn't it? So they might have a situation where they cannot yet upgrade, and would be happy about some level of continuing maintenance.
Also, when T6 has now become a free version, this should not downgrade its value to its users. But from that point on, for the new free users, and for the whole Tracktion/Waveform scene, I wouldn't talk about maintenance when investigating possibilities what to do with it, but
- I would talk about a strong way of advertising and giving proof of an actually excellent and reliable product and operative means of production for its users. Thus, the programming costs for the free version(s) would have to be tagged as advertising costs, and only to a minor part as a maintenance for lagging users.

The question really is, are there bugs in T6, that all have been killed on the way to Waveform?
Because if unfixed, after how many upgrades will it happen? Not that Microsoft were beyond such questions.
I wrote a million lines of code myself during a professional life, so I can say I see serious potential in something, or not.
I don't make money with music, but I believe in your mission to deliver a great piece of software with lots of add-ons and extra features. I love what I see here.
It does not deserve to be seen as "cheap". Just the market is what it is, and still it is possible to climb up a lot.

The math is still yours: Will successful T6 users, free or buyers, be a strong factor to convince others of joining, or can the demo version of Waveform do the job? A current demo version might be more inviting, but perhaps less convincing than an old version in full production.
I'm just mentioning, but of course I cannot judge the feasibilities.
-----


Open Toolbox, yes I'm aware that the plugin data blocks are some kind of black box, but I think some people would decipher quite a number of plugins and document at least the most relevant parameters. And then, you still have the data description for the inhouse filters yourself. A compare tool, that does just these and the structures, might already be of interest. Volume change for the git solo? Did we or not?
So we could have some open source scene about that, and it need not even be bound to Tracktion.
You would just need to allow it and handle it friendly, while having no responsibility on compatibility.

This happens with quite many software systems. There is a scene of indie add-ons, and everytime there is an upgrade, half of that stuff breaks, and when we talk Firefox, this is not so unimportant. People use their non-guaranteed extensions in quite important ways, and they openly know it. And still there is a myriad of Firefox add-on programmers. Statistics would be different because Tracktion scene has less users, but then also, the percentage of professional users might be more relevant than for FF. Companies use other browsers.
But FF gains much from the free 3rd party stuff. This keeps them a user base.

With a docu of current xml structure, 3rd party guys could program some tools, without costing anything to you. Just make clear, they have to accept changes, and warn people from lagging upgrades for that, which upgrading motivation anyway works only when there is policy of meticulous upcoming bug fixes AND documentation about that progress AND it is confirmed in the scene.

Do you really believe, professional users would not upgrade, when you release XML documentations? 3rd party programmers can never compete the core functionalities. They just can make life a tad easier. And when they are serious, they upgrade their stuff as well.

I believe there should be good harmony between software that is not expensive, and a big and fairly independent user base who also make add-ons (I mean not filters here), and have some club feel and an enthusiastic younger crowd also.


Editing operations? Just one example. I made me some dozens of racks, e.g. a 4 band transient designer, a detailed tweakable Maxbass harmonic synthesizer, and a poor man's Trackspacer with 4 Nova bands. ^_^
It seems there is no automated sorting of these user defined racks. It is a mess. Sometimes the new rack appears at the beginning of the list, sometimes it is buried randomly in the crowd.
Sorting would be a mandatory feature, perhaps with a deliberate click, but for now, someone who already understands the structure of the project and settings xml's, she might do the sort tool in a couple of hours. Of course it runs in batch mode and makes backups. I mean, for Windows at least, it can be done with CScript. Just drag the xml onto the script.
(I have all my plugins already in a meaningful folder structure on the harddisk. I'm not going to create a manual ordering.)

Another option would be an alternative way of moving projects and their track audio across the harddisk structure, and still run the project on the external hard drive. Finding disconnected material with T6 did not work for me. With T1, I even used a hex editor to move a project without manually reimporting everything.

BTW the internal ID key structure might have its own issues...
Though it is a very good and professional idea, it seems I can get stuck with automation of multiple plugins in racks, that have the same name (same name plugins, and same name racks; both a potential issue in addressing).
(Hint: When the readable name is dominant, I would solve issues with "tracked sorting". Insert an object, then a) it has to be sorted into the structure immediately by name, and b) the fact it was inserted as the 5th after 4 other insert actions, is somewhere stored in the data structure. This must be done because of duplicate names and the fact they are growing. Then later, the system routines can figure out where stuff went, and what its hierarchy means to the user, and where a plugin really is, after some others came to the party too, and changed the pecking order. Based on this principle, also all ID keys and relationships can be reconnected reliably.)

A serious problem is the default parameter of a rack. When the rack e.g. has 4 sidechain inputs with pan/volume gadgets, and appears in 4 send applications in 4 tracks, then for the default parameter should be selected the volume knob 1 for track 1, knob 2 for track 2, etc.
But for the duplicate ID, the functionality of the default parameter only can address the same LAST volume filter from all 4 tracks.
(ok here I can use the send volume in the plugin environment that the rack is using. But if it is panning or roll-off frequency?)
So, there are difficulties with addressing of plugin parameters within racks, in T5 this also happened with automation.

Another problem is that some racks do not save their internal plugin parameter set within the tracktion-edit. It recalls an empty plugin with some default setting, for all plugins in the rack, that are not Tracktion-made.
Whether this is because some plugin is misbehaving with its data block, I don't know. So far it seems random, but a couple of particular plugins make it seemingly worse, and having racks with duplicate names in the edit makes it "worser". I should not be able to create duplicate racks with the same name. Sometimes it adds (2), (3),.. sometimes not.

My technical theory about the issue is, when I use object oriented metaphorics, then when a rack is shared among a number of tracks, then ONE track should be exactly the parent object (and this is the master instance that it holds), and own all plugin parameter data for the whole rack, except we have a default parameter selection in another track for one of the rack plugins. This would just call a data change method in the rack's parent/owner track. Secondary tracks use a "borrow" or slave object that addresses and represents the same rack by its ID and does pass on all the methods/functions, and audio data.
Addendum: When I drag the [A] symbol to a slave instance of a rack, then the automation curve will be attached to the parent track of the rack. It will store the track ID of the slave instance of the rack, where we came from as using the automation, this is for backtracking, when we want to see 'all automation curves' of the track holding the slave instance. Else the "borrow" shell can't get a meaningful answer of its rack, as its parent track would know nothing about the rack regarding any other tracks. There must be a list of all borrow tracks that use the slave instances of the same rack. Technically, a master and a slave instance do not have different meaning or behavior in the mixing. This is all defined by the environment of the rack instance and by what the user is doing. Being a master instance or a slave instance is a purely organisational matter for the internal ID and object system.
This organisation should be transparent to the existence of multiple racks of the same name and structure. But it should give an automatic numbering to the racks.


I would appreciate to enter positive and also negative sample delay values in return bus tracks (whether they operate on the return plugin, or get audio from a rack.)

The Freeze pseudo-plugin is absolutely great but does not operate when tracks are interconnected with sends or with racks, or if they are addressed on the receiving side from other track outputs. Then the sending tracks cannot be bounced, which is a pity because they have a lot of plugins on their own, preparing something that can't be don in the buss.
But they MUST freeze this, because this is the purpose: complex mixes.
I would suggest the freeze plugin gets a parameter button that actually opens a text plugin surface, where the frozen structure is fully being documented. I.e. we must analyze which depends on what, and where the sends are demanding their own rendered replacement data. For circular references, it should suggest a breakdown scenario, means we can select a point in the structure, where the updating of changes ends, until we rebounce the new mix changes completely. Such a complex freeze will need the same time as a full rendering, but at least, we can listen to the mix, and adjust a couple of other tracks not in the freeze chain.

BTW some of my crashes probably are coming from the very poor graphics vector cruncher in my Windows notebook, which is optimized for data processing, not for games. (NVIDIA NVS 2100M)

Last not least, a funny glitch. When autosave is on, and happens every 2 minutes (so it can hit me), and then I render the mix with the export function, then while it is rendering, the autosave occurs, and cuts a hickup in my rendered result! Big oops.
I thought it were a plugin in demo mode, but now before rendering, I always(?) switch off autosave, and the glitch stays away.
So, do you temporarily switch off autosave during rendering already?


Let me conclude with an aphorism. The way things went so far, a user of a free version that is lagging only 2 version numbers, still might be seen as a legit beta tester!
(I was never intending to mess with your official bug reporting system, because there, I guess the priority should be on bugs that occur to the frequent and professional users.)

[pquenin]

I have not updated to Waveform because there are things that annoy me in T7 (and still in T8) :
- you can't rename a "filter" (a plugin). As I love the MUX VST by Mutools, Tracktion always shows me this plugin as "MUX", but the MUX VST is polymorphic, it can be a instrument, a sampler, an effect ,a midi arpeggiator, and so on, so it's a bit frustating not to be able to rename the various occurrences of this plugin in a song.
- I know Jules doesn't like that but there is still a "first note bug" in Tracktion : the exact same sequence with the exact same plugin and preset doesn't loop right in Tracktion, but fine in all the others DAWs I have tried (Mulab, Reason 9, Studio One...). It doesn't happen all the time, but with the Tone2 Firebird 2 plugin for instance, it happens systematically.
- Tracktion has problem with VST UI resizing, where some more modest DAWs as Mulab handle this perfectly. For instance, the Luxonix Ravity S VST is shown only totally opened in Tracktion, but it can be reduced/extended as expected in the other DAWs.
- T7 is the only DAW that I must set to 1024 samples to sound right on my PC (Windows 10). All the others DAWs sound right with 512 samples.

So I'm also searching for an alternative, maybe Studio One ?

[HansP]

I'm happy so far with renaming the plugin DLL and have a plugin rescan. I made me also a useful folder structure on the harddrive that groups my plugins.

first note: perhaps there is a conflict with starting a data array at boundary [1] or [0]

((caution to all windows programmers: newer screens&resolutions exceed integer coordinates. all graphics must be long integer now... I met this in VBA though.))

[Trancit]

I'm happy so far with renaming the plugin DLL and have a plugin rescan....

But this is not possible with a number of plugins...if you rename the .dll they simply don´t work anymore...

So this is not an option ...

...and +1 on the lack of being able to rename plugins... as the new custom plugin list was being implemented, this was the point that really disappointed me as many plugins have a really silly naming

EDIT: ...and of course, the lack of being able to rename single instances doesn´t make everything easier...

[HansP]

Yes, that would be a suggestion, based on a composite key concept in parallel to the linear ID structure that probably drives the audio engine.
When I organize my visible objects (insert, move, rename, delete), then some internal housekeeping must reconnect the structure with the linear IDs and also use some tracking of multiple instances, and backtracking of rack trees, in case the user does not rename things.
Renaming would be an inherent principle in this key system. Tracktion has something, but it needs to evolve in this direction.
This would even allow nested racks, but I would not recommend that, for when users exploit that idea, it would become a resource hog and project structure would have a complexity that becomes confusing.

BTW in T5, automation curves sometimes did not find their own plugin, when it was sitting inside a rack, together with other plugins with the same name, and moreso when the rack was used with multiple ocurrence (the top level of creating racks, that have then multiple instances each).

[fluffy_little_something]

Why on earth did they rename Tracktion to Waveform?! Waveform suggests a synth in my view.
Tracktion is an established product name and much more fitting...

[fanta1]

Why on earth did they rename Tracktion to Waveform?! Waveform suggests a synth in my view.
Tracktion is an established product name and much more fitting...

The name 'Tracktion' was the idea of the founder. So I guess, Jules is not involved anymore. And you are right: 'Waveform' is a free VSTI from Lithium Sound created at 2009.

[scalawag]

Tracktion is now the name of the company, so they had to rename the DAW to something else.

[HansP]

they are still advertising free T6 as a teaser to buy Waveform.

it's like a double trap because T6 does not handle intense professional requirements well enough, but OTOH I am not aware of a real alternative for the simple and clear workflow that is still extremely versatile.

[ErBen]

Honestly I wonder about the strategy of Free T6 etc. I even wonder about the pricing of Waveform. On one hand I shouldn't complain because I definitely got a great deal with the Waveform ultimate package, at least on paper (turns out Biotek and Collective don't work on my system, but hopefully this will be fixed).
But on the other hand I'm concerned that the team might not have enough resources for making it as great as it could be. I'm not sure what the OEM deal for T7 brings home, but T6 free + cheap Waveform + distractions like Raspberry support (who uses this here, anyone?) doesn't sound like enough money. I wouldn't put Linux as a distraction because without Linux support I just wouldn't be here, but Raspberry Pi?
I don't know what's the solution (Waveform doesn't seem to be in shape to go head-on competing with the big weights without the price advantage), but I'm worried.
But well, I agree with those above, focusing on stability rather than chasing features would be a great thing.

[gesslr]

It’s been very quiet, even in the beta group. Am hoping that all is well with the crew and they are busy beavering away on stability issues.

[gesslr]

Why on earth did they rename Tracktion to Waveform?! Waveform suggests a synth in my view.
Tracktion is an established product name and much more fitting...

Yeh. Waveform is a bit of an odd choice, but not terrible.

Everybody I know who knows of it still calls it ‘Tracktion’ (self included TBH). Perhaps they could have simply called it “Tracktion Studio” or “Tracktion Pro” for an easy differentiation.