search

hydrogen-music / hydrogen

The advanced drum machine for Linux, macOS, and Windows
http://www.hydrogen-music.org
GNU General Public License v2.0
1.06k stars 173 forks source link

Feature request: Apply drumkit within song to another song.... drumkit variants #1157

Open github-wlk opened 3 years ago

github-wlk commented 3 years ago

Hydrogen version * : Future Operating system + version : All Audio driver + version : All

Hi, I proposed an idea of having drumkit "variants" (see https://github.com/hydrogen-music/hydrogen/discussions/1134), and was corrected that the song files are essentially variants. So, would we be able to have "apply drumkit from song X to this song"? I admit that sometimes the collection of instruments will match, sometimes not. So, perhaps one could have a (pretty) diff listing, showing how the mapping would change, if at all, and perhaps allow one to re-map it. A parallel idea would be to have a graphic for comparing two drumkits (whether between two songs, between a song and the "default" kit, etc.)

Perhaps parallel to this as well, create the idea of drumkit variant or template (I know, I won't let this go), where it would simply save the drumkit data in a h2song file. I had proposed putting "template" in the name or something to distinguish it, but I realize that that is too difficult to maintain (anyone can put "template" in the name), so perhaps another field in the XML would specify "this is a template", and then when you save that song as a normal song (drumkit + patternlist), it would remove or change that novel field.

Yes, this should probably be 2 or more topics. I'm old. I escaped IT before Agile took over.

Thank you! I really like Hydrogen (although, admittedly, having been Linux-only for the past 25 years limits one's choices :) )

oddtime commented 3 years ago

what about the term "patch"? (as in kontakt)

oddtime commented 3 years ago

I've thought this could be done in this way: modifying the method int SongWriter::writeSong( Song * pSong, const QString& filename ) to int SongWriter::writeSong( Song * pSong, const QString& filename, bool bReadPatchOnly) rather than copying and paste many of the lines to a new function writePatch(

if bReadPatchOnly == true output file would have ".h2patch" extension.

To read I would change Song* readSong( const QString& filename ); to Song* readSong( const QString& filename, bool bReadPatchOnly); and it could import patch from both ".h2song" and ".h2patch" files.

If some of these ideas don't work I would write one or two new functions writePatch, readPatch. (I haven't looked into them yet)

@theGreatWhiteShark what do you think?

github-wlk commented 3 years ago

re: "patch" name... I have no issue with that as long as we aren't also using the word "patch" for any form of software updates. I just don't want any confusion. I don't know the code nor the culture/environment. Yes, "patch" can hearken back to old hardware synths, among other things. :)

Thank you for your interest and your work!

oddtime commented 3 years ago

Thanks for the idea! I am trying but it is longer than I imagined actually, especially if we want to undo/redo the action. I don't know how much time it will take, I am new to H2 developing, but still for now you could edit the .h2song file with a text editor.

theGreatWhiteShark commented 3 years ago

Hmm. I don't really like the idea of having yet another file format holding the drumkit parameters. As seen in the discussion it's already unexpected to find the custom drumkit parameters in the h2.song file instead of the drumkit.xml. Also it's a quite likely source of bugs since all the class definitions have to be kept in sync.

On the other hand, I can not really think of a good way to provide "apply drumkit from song X to this song" yet. Does it affects the instrument parameters and not the state of the mixer? What about the instrument pan that is displayed in the mixer? What if the drumkits differ in more than the parameters (e.g. a layer or instrument was deleted)? If more than a stock window for choosing the other file is required, the feature would become unfeasible since such a Qt window would need to be done from scratch to do basically just export drumkit & load drumkit. But maybe there will be a smooth solution popping up when implementing https://github.com/hydrogen-music/hydrogen/projects/2

oddtime commented 3 years ago

Does it affects the instrument parameters and not the state of the mixer

both in my opinion. Ideally you could choose if loading the humanization parameters as well

What if the drumkits differ in more than the parameters (e.g. a layer or instrument was deleted)

I think the patch should be saved in the same format of songs. (but with no info on the patterns and notes) I would load the settings of that song into the current song, without rewriting patterns. If the current song has less instruments, some new ones would be created (or not).

oddtime commented 3 years ago

(e.g. a layer or instrument was deleted)

regarding deleted instruments (or ordered differently), such flexibility probably can be solved together with https://github.com/hydrogen-music/hydrogen/projects/2

theGreatWhiteShark commented 3 years ago

regarding deleted instruments (or ordered differently), such flexibility probably can be solved together with https://github.com/hydrogen-music/hydrogen/projects/2

Right now there is no real way to tell the instruments of a drumkit apart (well, there is a name, but this can be changed as well). So, different instrument parameters could only be applied with respect to an particular order. Rearranging the instruments would break it.

would load the settings of that song into the current song, without rewriting patterns.

With so many things to load. Wouldn't it be more straight forward to export all patterns from one song and import them in another (which was duplicated first)?

oddtime commented 3 years ago

With so many things to load. Wouldn't it be more straight forward to export all patterns from one song and import them in another (which was duplicated first)?

Seems right. Then we would need a function to export the pattern sequence + the patterns

github-wlk commented 3 years ago

I was imagining something along the lines of a display of each drumkit (current on left, new on right), with H2 perhaps offering an educated guess (or just having a default top-to-bottom mapping). Something like the mapping in QJackCtl (and you can borrow rnc's code):

image

Perhaps have an indicator (on "current" side) if there are events attached to that instrument. Show whatever warnings necessary, not enough instruments in "new" drumkit, etc.

Thanks!

theGreatWhiteShark commented 3 years ago

Something like the mapping in QJackCtl (and you can borrow rnc's code):

Something like this is planned to be implemented for switching between drumkits (for version 1.2). But there are a couple of things that need to be done first. Right now, songs with different drumkits are in some sense incompatible since their patterns do depend on the drumkit and various things can go wrong.