#musicbrainz-devel

arguably that should just use * magic but for now I can just put in size

you say that to the author who barely knows python and has no idea what * magic is ;)

so

instead of what you did, you could have it be

def matches(self, *args): return self.pred(*args)

* magic is kwargs, I guess

which means unpack all other positional arguments into the variable 'args', in the first instance, and then 'unpack args into separate variables' in the second

** is kwargs

ok, I get the first bit - how does the second bit work?

which is the same with a dict instead of an array and keyword args instead of positional ones

as in, what does pred 'see'?

a dictionary?

so, imagining args has something like [200, 1024]

since with * it's always arrays -- ** will be dicts

ah, ok

then self.pred(*args) is equivalent to self.pred(200, 1024)

basically the * removes [] and ** removes {}, in a handwavey syntax-specific way of putting it :P

basically though, putting *args as the second "argument" to matches, and the only thing passed to pred, just means "pass along all the positional args"

which is probably basically what we want

cool, and it appears to be back

I've provisioned all three servers

this was just with adding size deliberately, not with *

yay

dataz

yay, finished all my schema change work

wow, nice work.

otherwise likewise though :)

well i didn't really have any :P

drop a table and add a column

hehe

I guess places and _name tables are the two big ones this round

ocharles: still on time to decide you want to do series then :p

god it'll be nice to be rid of those _name tables though

hating them even more since I've been working on expunging them :P

reosarevok: I would like to keep this schema change pretty slim

amen to that.

to make matters worse, I'll be traveling at the time.

ocharles: well, you can always ship them in May :p (I just want someone to commit to write them because if not we're never going to make it :( )

in SLO, ironically enough.

hah

I guess I'll be traipsing off to CA shortly after we do the release too, huh

ianmcorvidae: i can't wait to be rid of those tables, too :)

well, I guess if something does go to shit two of us will be in the same room at least :P

(took ages, but)

define ages.

Couple hours

thats problematic.

That's unavoidable

that means at least an hour of downtime. :(

We're rewriting the whole thing to remove _name tables

So unless you can go back in time to stop us from adding them...

Mind, rika is a slow server

we can always do it right now to a separate table, and write triggers to materialise on the fly

then at upgrade time we just flip the tables

that part was 70 min on rika, 40 min at ian's server

(is one approach)

Dunno how long it will take on the actual servers

the downside then is our upgrade.sh is not what everyone else has

One hour of downtime isn't that bad

yeah.

and totoro is respectably fast.

has fast drives in raid-1,0

yeah, I'd bet totoro will be faster than my local system

which in turn was faster than rika

of course others will have to run it on weaker systems, but

Which in turn will be faster than a VM, right?

if they could handle the track ID one they can handle this :)

(on my system this was about comparable to the track one, in fact)

oh fun.

yeah, VMs will probably be slower

oh speaking of broken clietns.

Hopefully we'll handle this better than we handled the track ID one though :p

the freedb gateway hasnt been updated since may.

no

I fixed that

Did someone notice?

you were on vacation at the time

I mean, it took a couple months, but

ah, ok. thanks!

er, well, assuming I got the code part

the database is updating, is what I mean :)

so thinking about it further it may still be broken because of code stuff

so, while I have a few of your here, Xavier from the MTG is proposing a new project.

first off, this was open sourced recently: http://essentia.upf.edu/

its a versatile kit for audio processing.

and extracting feature vectors from audio streams.

with lots of *arbitrarily bolded* chunks of text in the *middle* of paragraphs!

however, looks cool

and now that MTG has access to a large collection of music via the IA, its working to extract the features from that music collection.

ianmcorvidae: but but but *complemented*!

so presumably the notion is where do they put all this awesome data they're extracting?

So, where do we go in?

those feature vectors would make a very nice basis for building recommendation systems.

ianmcorvidae: exactly.

the idea is to build a system that given an MBID, you get the feature vectors.

as an API. as well as downloadable data.

they are gathering the data, and I think it would be a good thing for us to host.

sounds good

seems reasonable

How do we display it?

Or are we talking just throw it in a server?

not sure if it makes sense to display it.

presumably we'd want a separate project of some sort for the API bits, and ideally we'd split out our replication code so we can output separate replication packets for it if we want to do that

its not friendly to humans kind of data.

ianmcorvidae: yes, totally separate.

well, how we display it, if we do, is by writing our own recommendation engine and putting related $whatever links on pages

but under the metabrainz umbrella.

ianmcorvidae: yep. recommendation engine is exactly where this is going.

yeah

I'm not so sure about us writing our own engine, but :P

i don't think we should be thinking about getting into the recommendation business

because that is *hard*

hosting the data, however, is right up our alley

yea

so that I'm down with

ocharles: its hard because of lack of data.

my point was just that if we want to display it that's how we do it :)

70s ianmcorvidae is down with that

hey, you've seen my hair ;)

:)

He can dig it

I'm really interested in enabling all of this/

ruaok: that is part of the problem, but not really the crux of the problem

ruaok: so, say yes first, think what else if anything we do about it later? :p

ocharles: yes, but the MTG has the type of people on board who love to work on shit like that.

reosarevok: yep. :)

ruaok: If that means *they* write it not us, sounds good :p

as reosarevok said, we should do this and then see what comes fromit.

not that it'd necessarily be an awesome engine

but it'd be some sort of one :)

but yea, all for hosting this and providing an api

We can also host *that* later

ianmcorvidae: a first step would be good.

ok, good. thanks for the sanity check, folks.

reosarevok: I want that so bad.

ruaok: what does it need? Apart from disc space that is

I mean, if we're implementing an API it needs that

software.

if we aren't, it needs some sort of software still

in terms of uploaders and whatever assorted crap

for the essentia stuff, the api could be pretty simple.