-
Notifications
You must be signed in to change notification settings - Fork 13
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
enable decompilation to ALDA #53
Comments
It only makes sense to have a concrete target language. Therefore I think ALDA makes sense. |
An idea to consider: it might be useful to decompile to MIDI, and then do a code generation phase that generates Alda. In other words, if you're at the point where you have a MIDI sequence in memory (or some other sort of low level MIDI representation), you could use that representation to generate Alda code. In fact, if you did that, then we could potentially reuse just the code generation part to build a MIDI import tool for Alda (https://github.com/alda-lang/alda-core/issues/25) :) |
It's already planned that way. |
Perfect! |
- separated MIDI related from MidicaPL related parts - enhanced the file chooser to support tabs for different export formats - prepared support for other decompile target languages - #53
Just trying to implement META messages for tempo, key signature and time signature. @daveyarwood, what about the time signature? |
One of the interesting things about Alda is that it doesn't really have measures or time signatures. There are barlines, but they are purely for aesthetics / code organization. At some point, I would like to make barlines meaningful and use the lengths of notes between barlines to infer time signatures so that we can include them in the MIDI sequence. But right now, Alda is completely agnostic to time signatures. I think for what you're doing (going the other way, MIDI => Alda), you can just not translate time signature meta messages. I suppose if you really wanted to, you could emit |
OK, then I'll just ignore them. |
- still missing: adjustment of notes names to the key signature - #53
- something's still wrong with some note lengths - channel-based attributes still missing - #53
- avoid exceptions when decompiling lyrics-only files - moved debugging methods from the exporting classes to the parent (Decompiler) - bugfix in the ALDA decompiler - #53
@daveyarwood the ALDA exporter is now working. Limitations:
Regarding the last problem: Do you see any way to mitigate that problem? |
Just fixed 2 bugs. Should work now in most cases. |
Awesome! I'm excited to play around with this sometime soon when I have a little time.
Ah, interesting. Unfortunately, the approach I took with Alda doesn't work well in the context of importing MIDI files that work this way. Alda doesn't really have a notion of a part "switching instruments" like you can do on MIDI channel. On the other hand, several years ago I had some thoughts about how to support having more than 16 instruments in a single Alda score. See alda-lang/alda#178 and https://github.com/alda-lang/alda-sound-engine-clj/issues/5 I'd be curious to hear your thoughts. It's still something that would be great for Alda to support. Another idea I had just now: right now, Alda doesn't let you specify which channel to use for an instrument part, but perhaps it could. I imagine we could add an attribute like
|
For the decompilation that would be perfect. It would have made my work much easier if ALDA had such a feature. But on the other hand something like this would not be possible:
So it's up to the user to avoid such a thing. That makes the language more complicated. |
On the other hand you can assume that a user using this feature already knows what he's doing and why. |
Yeah, the more I think about this, the more it feels like it would be a good thing to add to Alda. I'll put it on the TODO list for Alda v2. I've also captured the idea in https://github.com/alda-lang/alda-sound-engine-clj/issues/5 so that I might implement it in Alda v1 as well, but it might be a while before I can get to it. So far, I'm thinking that this will be an "assume the user knows what they're doing" kind of feature, like you just described. It would be sort of like a low-level escape hatch to work around Alda's default behavior of automatically finding an unused MIDI channel for each part. If two parts both include |
1.
The decompiler contains MIDI specific and MidicaPL specific parts.
Separate these parte into different classes to make it easier to export MIDI to other languages.
Currently the inheritance hierarchy is:
MidicaPLExporter <-- Exporter
It should be this:
MidicaPLExporter <-- Decompiler <-- Exporter
Move the MIDI specific parts into the new Decompiler class.
2.
In the main window there should be only one Export button for all decompilation classes or maybe even only one for all exports.
3.
The file choosers for export files should be in the same window.
The type may be chosen by a tab or something else.
The decompile options (and maybe other settings) can be the same for all files being exported.
4.
Add an AldaExporter class, derived from Decompiler.
The text was updated successfully, but these errors were encountered: