Skip to content
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

Open
brianbreitsch opened this issue May 15, 2016 · 4 comments
Open

Comments

@brianbreitsch
Copy link

A Sequence as an Event is currently specified as follows:

[time, "sequence", data, rate]

Parameter rate seems to belong to interpretation.
In the case that data is a Sequence object, this can go into interpretation.
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 the rate param into an override param or something of sorts.

@brianbreitsch
Copy link
Author

In fact, it would be convenient to make Sequence derive from Event, treat their name as a unique identifier, and remove the rate param or make it an override param to override the interpretation.

@brianbreitsch
Copy link
Author

brianbreitsch commented May 16, 2016

Scratch that last comment about all sequences being events....I'm still learning. :)

@stephband
Copy link

stephband commented May 16, 2016

My take is that rate is more than just interpretation.

If I have a sequence, say:

{
    name: "Marvellous Sequence",
    events: [
        [0, "note", "A", 0.75, 1],
        [1, "note", "C", 0.5, 0.5]
    ]
}

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:

{
    name: "Master Sequence",
    events: [
        [0, "sequence", "Marvellous Sequence", 1],
        [4, "sequence", "Marvellous Sequence", 0.66666667]
    ]
}

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 "transform", transform-param-1, transform-param-2, ...:

{
    name: "Master Sequence",
    events: [
        [0, "sequence", "Marvellous Sequence", "rate", 1, "transpose", 12],
        [4, "sequence", "Marvellous Sequence", "rate", 0.66666667]
    ]
}

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?

@brianbreitsch
Copy link
Author

@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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants