Comment 8 for bug 1476290

Revision history for this message
Jim Siler (j.siler) wrote :

@uklotzde Sorry to react so slowly, especially seeing how quickly you responded to me. I just started looking at your OpenAPI spec for aoide, and the other links you shared. Looks interesting, but at this point I haven't much of an idea what it is. Do you have a project summary somewhere that I can view?

I agree that Rekordbox's _internal_ approach is simple and sensible. And there lies my frustration. It leaves them so close to a product that I can use that I can almost taste it. But they fall short on implementation. Three very simple features would vastly improve the product vastly for international and other music which uses real musicians to set the pace rather than an 808 drum machine.

1 -- Allow an individual beat marker to be moved. It is horribly frustrating to have spent a long time bet marking a track to find that an early and critical marker is a bit off, and that changing it will screw up the entire track forward of the change.

2 -- Permit editing a range of the track, locking the rest. Currently Rekordbox allows users to set a point at and beyond which modifications can be made, locking everything prior. This change would require the ability to designate an end point forward of the start point at and beyond which the beat grid is locked. (Strictly speaking 1, above is a special instance of this, but it really would help to be able to use a "shorthand" of this feature on a single marker.

3 -- Apply a different time signature and/or explicit beat (eg., 2 for the second beat of a 4/4 measure) at a given marker. This would propagate forward, stopping at the end mark of the edit region

All of these can be achieved by manually editing the rekordbox.xml file and then importing the collection from it. Rekordbox supports these edits, including respecting arbitrary time signatures other than 4/4. It is so frustrating to know that a relatively low effort level set of changes that are completely consistent with the Rekordbox architecture should be missing. Someone clearly envisioned them when specifying the xml format, and someone implemented the capabilities in the underlying engine.

A couple other potentially useful features would be:

1 -- The ability to tag a key change. At the risk of annoying the true DJs out there, this could help support auto-mixing.
2 -- Implementing named sections in the XML, as Rekordbox now does internally. Useful for both manual and auto-mixing.
3 -- The incorporation of lighting and other cue points in the XML.

These are the frustrations that lead me Mixxx. At least Mixxx gives the (possibly illusory) possibility that I can implement the features I want instead of pissing and moaning that no one else does.

Jim