someone sent us a PR, but really wants to remain anonymous.
alastairp
interesting
shivam-kapila
Maybe they like the project n use it but werent on gh
alastairp
well, they made an account, so I don't think that was it. we have plenty of other ways of them getting information to us
it seems like they just don't want their contribution to be public, which is fine
Rotab has quit
ruaok
I don't have a problem with it at all -- its just a rather specific PR with a new account.
which is interesting from a "how much adoption is LB getting perspective"
Gazooo79494 has quit
alastairp
it seems like they're running the code and found a bug, but don't want their involvement to be known
which is super interesting
shivam-kapila
Sherlock holmes needed
ruaok
> which is super interesting
yes, exactly.
no need to dig up who this person is, that is far from my point. just interesting that someone did this. could be a "we should be paying for support, but we want to stay off the freaky haired guy's radar".
Gazooo79494 joined the channel
shivam-kapila
Lol
ruaok
yep.
Rotab joined the channel
alastairp
ruaok: any pending PRs needed?
I was going to take a look at integrating year + artist into the annoy patch, then take a look at some of the open issues
ruaok
Come again?
alastairp
do you have any PRs that you need me to review
ruaok
Ah. Hang on
no, looks like we're all caught up.
a couple of things I'd like to discuss though.
Mr_Monkey
Alternatively, maybe the mystery contributor's work contract prevents them from contributing code to other projects.
ruaok
first, having year is good -- that was a pile of effort and that will solve some problems, but I am not sure it alone can solve my daily jams issues.
I want to be able to filter on genre, but that is another whole can of worms really. any thoughts on how to deal with genres in this context?
I made a start on that, though we have to make some decisions about if we should try and match similar-but-not-quite genres compared to ones that are already in MB, or if we just import them as-is
however, this is only going to handle the small subset of recordings for which we have this data
ohhh, with official sanction from reosarevok. yes, this sounds great.
> however, this is only going to handle the small subset of recordings for which we have this data
alastairp
should we get a move-on with jmp_music__'s classifier tools, and build a better model based on this data? we have some baselines from UPF which are much better than what we have
ruaok
I wonder if ACRM could also aggregate these.
alastairp
though that's a 2-month job, not a 2-day job
ruaok
maybe early next year on that, methinks.
alastairp
yeah, sure
ruaok
I could help, but right now there are other low hanging fruit I would like to pursue.
actually I'm happy with that as a road-map for genres for troi. let me stew on that a bit and then figure out how to schedule that.
alastairp
OK, I'll take a look at the genre import again then. there are few things I'd like to talk about with someone regarding this. maybe you or reosarevok or both
ruaok
also, playing with funkwhale over the weekend....
Mr_Monkey: this addresses one of your concerns about lack of playlist import/export.
FW has plugin support -- I haven't dug in yet, but if plugins can create playlists, then it should be pretty simple to make a troi plugin for FW.
which is *really* neat if you think about it. FW has context over the users collection...
so that CF and annoy results can be constrained to the available tracks in the pod.
or in the case of aggregated pods, don't bother with that can just make playlists.
Mr_Monkey
> if plugins can create playlists
Do you mean create a playlist in FW or in LB? Because FW (and soon™ LB) has an API endpoint for that, which could be all we need
ruaok
right now I am feeling pretty happy about some troi decisions (no data to download, small footprint)
Mr_Monkey: in FW. it may be a shorter route than adding playlist import support to FW.
alastairp
for FW -> recommendations, are you thinking that a pod will have to submit data (AB, listening data?) to MeB sites in order to get data, or do you see a version which is fully self-contained?
ruaok
alastairp: FW can scrobble already, so I am using that as the base assumption. If you scrobble your listens to LB, troi works better than if you dont
alastairp
sure, makes sense
ruaok
and still heavily lean on the MeN hosted data sets to generate playlists.
first cut I am thinking about a very simple drop in.
in any case there will need to be a content resolve built for FW, which is likely going to be the largest amount of work in this context.
*resolver
Mr_Monkey: which also applies to the approach of creating playlists in FW via their API endpoint.
Mr_Monkey
Yes, the content resolver will be key.
ruaok
I think I might make FW my project of choice for between xmas and nye.
reosarevok: FYI there seem to be two problems, I'm expecting ws/2/work JSON to return type_id attributes when it actually returns type-id (has something changed recently?)
and I don't pass the key tonality correctly in my POST
I remember already having problems with that before
I'm working on the weekly-jams-flashback patch in troi. fetch all the recs for a user, sort by year and then make decade playlists if at least X tracks are present for a decade.
this means the playlister now needs to output more than 1 playlist.
I could make a new playlister element that is specific for this.
or the flashback element could output N sets of recordings and we could adapt the playlister to write a playlist for each of the sets of recordings.
alastairp
mmm
ruaok
the playlister with more than one set for recordings would need to have some playlist metadata passed to it.
(e.g. 80s playlist, 90s playlist, etc)
alastairp
I like the second idea
ruaok
I'm learning towards that as well for resuability sake.
but the playlist metadata bit is... unclear at best.
alastairp
so the input of that element could be [Playlist], rather than [Recording]
then class Playlist has metadata, and a [Recording]
ruaok
oh!
I had originally thought [[Recording], .. ]
and playlist contains metadata. yes. that is a good solution.
more work, but it makes sense to have Playlist as a troi entity
alastairp
great
anything you want me to work on for that, or do you have it?
ruaok
and then the playlister could be adapted to take [Recording] and output one playlist or [Playlist] and dump a series of playlists.
I should be fine. I'd love to see the similar tracks element moved along.
s/element/patch
alastairp
the "playlister", do you mean the playlist method in cli? or the Playlist element?
ruaok
the latter.
hmm. my daily jams is doing a good job of playing tracks I like from artists whom I generally dislike.
alastairp
oh yeah, I see now.
sounds good
ruaok
k
alastairp
I guess we don't have a lot of negative feedback yet
ruaok
I'll get moving on that. I wanna finish the weekly flashbacks element.
s/negative //
alastairp
I mean, no way of specifying negative feedback, and having that integrated in results
ruaok
soon.
alastairp
could always temporarily have a "remove artist x" filter
ruaok
>could always temporarily have a "remove artist x" filter
don't get me wrong, I'm praising our work!
loujine
reosarevok: the latest version should solve the problem, test when you can and ping me if there is still a problem
ruaok
and troi already has the RemoveArtistFilter. I nearly called it the RemoveRadioheadFilter()....