-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sequence Event--suggestion for generic "override" instead of rate #5
Comments
In fact, it would be convenient to make Sequence derive from Event, treat their name as a unique identifier, and remove the |
Scratch that last comment about all sequences being events....I'm still learning. :) |
My take is that rate is more than just interpretation. If I have a sequence, say:
Then I should be able to play that sequence back anywhere, at any rate - in fact with any old transforms applied to it - without affecting the original sequence. Eg. here it gets played twice, at two different rates:
If I am forced to include rate data as part of the sequence, this becomes impossible - you have to duplicate the sequence to have two copies that play at different rates. In fact I have come to understand 'rate change' as a transform, and I think it would be nice to be able enable any arbitrary transform or transforms on any event. The current way I'm thinking about doing this is to make events accept an arbitrary number of extra parameters in the form
I'm not yet totally convinced it's a good idea. It is not without disadvantages. For example, it would then be possible to write exactly the same tune an endless number of different ways. Perhaps this is not bad. Perhaps it is. I can't decide. We're all still learning :) Any thoughts? Also, BTW, what is the application you are most interested in, notation rendering, live or playback? |
@stephband Right now it's notation rendering using the VexFlow library. I am aware of VexTab and VexJSON, but I would like to have an in-memory data model that I deem more conducive to realtime manipulation. As for rate--I agree that the rate parameter is powerful, and think it should stay in the spec. What is wrong with the idea I proposed of moving the rate parameter into interpretation and making the 4th parameter of a sequence event an override object that allows overriding the rate, among other parameters? |
A Sequence as an Event is currently specified as follows:
[time, "sequence", data, rate]
Parameter
rate
seems to belong tointerpretation
.In the case that
data
is a Sequence object, this can go intointerpretation
.In the case that
data
is a reference to a sequence dependency, there may be other parameters about the sequence one wishes to override, in which case, we could change therate
param into anoverride
param or something of sorts.The text was updated successfully, but these errors were encountered: