hydrogen-drumkits package

[Jaromír Mikeš]

2015-09-16 13:22 GMT+02:00 IOhannes m zmölnig <zmoelnig at umlaeute.mur.at>:
> On 09/16/2015 10:41 AM, Jaromír Mikeš wrote:
>> Ok ... if we thinking packaging these files what about licensing?
>> There is already one bug opened ...
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773246
>>
>> IOhannes can you suggest complete list of packages we could provide
>> and containing drumkits?

> - first of all, upstream doesn't "release" (in a formal release-process)
> drumkits at all.
> i don't think that attaching the hydrogen version number to the drumkits
> is a very good idea in the first place (sticking with the date of the
> snapshot is saner)

Make sense to me.

> - upstream doesn't even provide a tarball for the drumkits.
> instead we (Debian) create a fake tarball by aggregating all downloads
> published via their drumkit feed (DKF).
>
> that's a slightly awkward situation.
>
>
> - the DKF provides some extra information (author, description,
> license,...).
> since the upstream tarball is synthesized anyhow, this information could
> be used to synthesize debian (binary) packages as well: just provide a
> single drumkit per package¹.

Ok

> the biggest problem i see here, is that this makes the number of Debian
> packages variable.
> otoh, if we are not doing too many snapshots and keep old drumkits (not
> published by upstream any more), then the work should be reasonable.
>
> i *think* this should be done semi-automatically, using a script
> downloading the drumkits and providing a debian/control stub that has
> all the information updated.

That would be great if doable.

> - licensing is a *complete* mess.
> the DKF is kind enough to provide licensing information provided by the
> authors (in a free form; so not really machine parsable)
> cool.
> the bad news is, that many drumkit package creators did not care about
> licenses, and just left the license field empty :-(

That's what i was afraid :(

> worse, some drumkits have a license text like:
>  "Do not redistribute or publish the inluded samples."
> here's a list:
>  - GSCW Kit 1 (Flac edition)
>  - GSCW Kit 2 (Flac edition)
>  - Roland_MC-307_CR78&Cheaps
>  - Roland_MC-307_TR-606
>  - Roland_MC-307_TR-808_
>  - Roland_MC-307_TR-909
>  - Roland_MC-307_Techno1

:(

> which leaves only these drumkits that have a free license (mostly some
> CC; and 'Lightning1024' says "Free!" whatever this means)
>  - DeathMetal (sf)
>  - circAfrique v4
>  - BJA_Pacific
>  - The Black Pearl 1.0
>  - Gimme A Hand 1.0
>  - rumpf_kit_z01_gm
>  - belofilms.com - AC-Guitar-Strums (flac)
>  - Audiophob
>  - Drumkit excepcional
>  - Lightning1024
>  - Denon CRB-90

These are also probably problematic as Fabian mentioned :(

> that's still 194MB, but having a closer look reveals, that 136MB of
> those are consumed by "belofilms.com - AC-Guitar-Strums (flac)".
> which is not a proper drumkit at all, so i guess it could be factored
> out into a separate binary package.
> i haven't checked the rest, but if they are all "drum" kits, then we
> might want to put them into a single package (~58MB).
> or split them into something like:
> - hydrogen-drumkits-classical
> - hydrogen-drumkits-ethno (or hydrogen-drumkits-percussion)
> - hydrogen-drumkits-electro
> - hydrogen-drumkits-effects

I like these categories

mira