Replies: 1 comment 1 reply
-
|
Hey @mrhanna! Thanks for this, the music implementation has been the most fluid thing in OpenMarch and a lot of time has been spent experimenting with different systems.
Answering your questionsPreambleWhen designing the music system, I had the following non-negotiables
Beat StorageFirstly
This is correct. All of the timing/tempo data lives in the Base tempo off drill pages
I understand what you're saying here as the end product has the tempo data attached. The reason I intentionally made the tempo data separate from the pages was so changes in page length during the designing process didn't upend
They do have set lengths, but not for long. The new curved path system is going to introduce customizable midsets. I say this, but the midsets are actually using the progress from the current page to the next, not an individual beat export const midsets = sqliteTable(
"midsets",
{
id: integer().primaryKey(),
/** The ID of the marcher page this midset is going to */
mp_id: integer()
.notNull()
.references(() => marcher_pages.id, { onDelete: "cascade" }),
x: real().notNull(),
y: real().notNull(),
/** The progress placement of the midset on the marcher page */
progress_placement: real().notNull(),
created_at: text().default("sql`(CURRENT_TIMESTAMP)`").notNull(),
updated_at: text()
.default("sql`(CURRENT_TIMESTAMP)`")
.notNull()
.$onUpdate(() => sql`(CURRENT_TIMESTAMP)`),
path_data_id: integer().references(() => pathways.id, {
onDelete: "set null",
}),
path_start_position: real(),
path_end_position: real(),
notes: text(),
},
);
This I 100% agree with, it's currently super annoying. I do think there's ways around this with our current system. You mentioned #512, which proposes a solution to exactly this Event markers
As you deduced, tempo groups are just an abstraction around beats so that users have a sensible way to edit them. In a way (and tell me if I'm missing this mark) tempo groups are distinct event markers. What OpenMarch is doing is just reading the durations of all the beats, calculating what the "tempo" is ( The goal of tempo groups was to create some way to mark changes in the tempo, and then the beats in the database would just be updated to reflect that
This highlights a big reason I picked individual beats. I almost went with easing functions, but the more I thought about it, the more I realized I have no idea how people want tempo changes to be done. Creating the individual beats was essentially me throwing my hands in the air and being like "they should just be able to define the tempos themselves if they really want to" One hole I think creative software can fall into is the developers assuming they know what the designer wants for all things. There are cases where this is true, i.e. a line is always a line and the designer doesn't want to make every little decision involved with that. But, we have no idea what audio files designers are writing their music to. If we define our own easing functions, there will always be some edge case we never thought about.
I believe it already does this, but am I missing something? The page starts at a certain beat and then goes until the next page starts
Rehearsal markers already kind of do nothing, but they do differentiate groups (so I guess that's something?)
This is what we were trying to avoid. When we make everything a beat, we don't actually care about what the time signature is. We just care about how much time a beat should take up in the music and how often it should occur. This goes back to the "drill-writer not DAW" idea. EpilogueI think you are right on the money with event markers. This makes a lot more sense from a user perspective. I say this was the goal of tempo groups, but it has already lead to a lot of confusion and there is a ton of current limitations SO, going from here, this is what I think:
Sorry for getting back to you so late, but thanks so much for this! Lmk your thoughts |
Beta Was this translation helpful? Give feedback.
-
|
@AlexDumo Wow, I really appreciate your detailed response. And I'm sorry it has taken me so long to acknowledge it. I read it the day you posted it but life has been too crazy with the start of new semester among other things to work on it and write a response. I have been thinking about it in between other things though! On Beats
I absolutely agree with you here, the beat is the most important thing. Everything a marcher should care about (positions, midsets, etc) should hook to beats. And yet, I can't shake the feeling that the duration (for example) of those beats shouldn't be the "truest truth" off of which other parts of the software should base calculations. Maybe I'm too stuck thinking in terms of DAWs and notation software, but it feels unnatural to express beats fundamentally as "having 500ms of duration" rather than "quarter note = 120." I understand that the current implementation of "tempo groups" abstracts these durations away for users, but if I understand correctly, what we're doing with that information is storing beat durations and deriving tempo from it:
This works fine when the tempo is steady, but what about when the tempo changes? Say that there's an actual accel/ritard in the music, or maybe the ensemble is rushing or dragging on the reference recording? On the one hand, you're right, "since everything is an individual beat [with individual durations], we can do literally whatever we want." So the user could make manual edits to beats to make the tempo change happen. Or maybe (more likely) the user could use a plugin to apply changes to those beats, or something like that. And for all intents and purposes, it would work fine. But as far as I can tell, as soon as they do that, and the software has derived those beat durations from whatever the user did to change them, the software has lost its ability to infer what the user was trying to do in the first place. The result is persisted, but the intent is not. For example, if there's an 8 beat long ritardando, now we're basically stuck with 9 new tempo groups. And you can play with those tempo groups and get exactly the effect you want. But I would love to at least have the option of seeing this expressed in a way more natural to most musicians - start tempo, end tempo, configurable ritard. The Core IdeaI agree that "beats are everything in marching band." Right now, beats are the central truth in the software, and their durations and positions are persisted in the database. But I posit that this is unnecessary - beats ought to be the central unit of measurement of time in the software, and the central truths ought to be event flags and positions (pages, midsets, anything really). Any attributes related to beats (i.e. duration) ought to be derived from these new truths. I will attempt to paint a picture of how I think it should work, then try to answer to your non-negotiables. How it worksEverything hooks onto beats, including event flags. Let's say we fetch all the flags from the database, and it looks basically something like this:
With just this information, any "duration" info (such as is currently stored in the beat table) can easily be derived by referring to whatever flags are in effect and doing some math:
I don't really see any downsides to this approach, besides dev time. But on the upside:
alexdumo non-negotiables
I think in principle the intention of this idea is to make UX and DX more intuitive without sacrificing flexibility. Intents like tempo changes are hopefully more intuitive to present, configure, and persist than before. And at the end of the day, if you're dissatisfied with the tempo change options (unlikely, more on that later) there's nothing preventing you from doing it the old way in this new intent-based approach - nothing is stopping you from putting a tempo flag on literally every beat to effectively define its duration explicitly. Mixed meter/time signature need not be affected.
see previous note - nothing is preventing a future feature or plugin from effectively doing things the old way, and meanwhile, new options are made available.
This one is interesting and I've been thinking about it a lot. I think this is achievable in the intent-based design. OpenMarch having an exact tempo isn't necessarily important in the same sense as it is important in a DAW, it's more a matter of user convenience. An idea I had about this: Let's take the likely scenario that someone is designing drill to a live recording. The piece is written at 120bpm. So they put page 3 at measure 17 and then page 4 at measure 25, but when they play it pack, they notice that the animation is behind the recording. And it wasn't the fault of the software, the ensemble just rushed those measures a bit. I think a clean solution would be: implement a timeline view that displays a visualization of the audio file (like a DAW, but we needn't implement any actual audio editing) parallel to the pages and a beat ruler. They drag the end of the page (or the beat attached to the end of the page) to the correct point with respect to the audio visualization. Using the new explicit page duration, the software calculates the average tempo needed to compensate for the change, and automatically inserts a tempo change flag at measure 17 (the beat number at which it is plotted is derived from the preceding meter flags, etc). Now the animation is relatively in sync with the recording. Now this I think is the interesting part. We didn't account for exactly when the ensemble rushed. So it's likely that the actual beats rendered on the timeline might not sync perfectly with the recording. I can imagine three possibilities in this scenario:
End NotesOne unrelated point of clarification:
I didn't intend for tempo to be based off of drill pages, but rather, project length. And this only as a practical side-effect: with beats being fundamentally a unit of measurement, and events being definable at any position on a theoretically infinite timeline, the project "ends" when there are no positions left to render, not when it runs out of beats. If you made it this far, thank you so much for considering the ramblings of an amateur programmer! I'm having fun thinking about this, and I hope I'm being a help and not a nuisance. Thanks for taking the time to read my thoughts and explain yours to me! |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello! I'm Michael, I'm a freelance musician and aspiring developer. I've been wanting to get my feet wet in open source for a long time, and I'm excited to have found a music-related project that aligns with tech I'm familiar with!
I'm still trying to onboard myself with the project and am curious about the state of beats and tempo groups. There are several open issues related to this (#591, #512, #393, #392). There's a lot of code already written in this area, but wondering if I have the gist right: it looks like every beat in a show lives in the database in the Beat table, and in essence, the TempoGroup tools provide a high level way to manipulate those low level beats in bulk.
Do I have this right? What is the advantage of persisting each beat?
Possible alternative?
If so, I wonder from both a UX and DX perspective why the model of the timing system couldn't be simplified to a series of discrete events (e.g. tempo changes, meter changes, rehearsal marks, repeats, etc), without involving "groups" at all. Not unlike keyframes.
Rather than basing the number of measures/beats in the project off of data defined in tempo groups, base it off of drill pages in the timeline.
Rather than defining tempo and meter changes with tempo groups, define them with discrete event markers.
I suppose with less information persisted, more math would have to be done on the fly for animation, but the math for timing keyframes should be relatively simple, right?
Beta Was this translation helpful? Give feedback.
All reactions