hpr-knowledge-base/hpr_transcripts/hpr0241.txt

Episode: 241
Title: HPR0241: What I learned from Oggify 
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0241/hpr0241.mp3
Transcribed: 2025-10-07 14:41:47

---

Music
The following presentation from the Utah open source conference held August 28th through
August 30th, 2008, is underwritten by Knowledge Blue. With the mission to help grow your company
focusing on small and medium businesses, KnowledgeBlue.com. Streaming and podcast hosting bandwidth
for this and many other presentations at podcast.utls.org has been provided by Tier 4. The presentation
entitled, What I Learned from Agify was presented by Scott Paul Robertson.
So how many of you have actually heard of Agify or used it? Cool. So just to give you the
rundown of what it is for those of you who don't know. So I'm a bit of an audio nerd or
audio files. Some people refer to us. And because of that, MP3s have an issue. They sound
like crap on high end speakers. And so I got a good speaker system I was in college and
I needed some way to keep that good quality. I mean, good if we won't get into vinyl. But the
good quality you get from CDs. So there are lossless codecs like FLAQ. But these aren't very good
when you have a laptop that has a 20 gig hard drive. Because they're big. They only give you
about a 50% compression. So I needed to have things in August. So I wrote a script back
in mid 2005, like early summer, that took a directory of FLAQ files, you know, with my fancy
directory layout, you know, artist, album, file names and all that. Preserve that directory
structure and file names. But encoded everything is augurbis. This was great. It meant I could
carry it with me on my laptop and not fill up the hard drive, which was really easy to
do. FLAQ, like I said, is big. My hard drive was very small.
For a while, it wasn't the intention of getting rid of the FLAQ files. It was just a healthier
and small laptop. Yeah. Yeah. It was to provide portability. Let's be honest, it's not easy
to get portable players that play FLAQ unless you go for the Korean ones, which I don't like
there to face. What is it? Is it Korean? Oh, I guess the Chinese have started. And of
course, you can hack your old school iPods too. Works well. But nevertheless, my laptop
it just wasn't an option. I needed something smaller. But it was really quick that I needed
something that actually was more robust than a shell script because you hit the upper limit
of a shell script really quickly for at least maintainability. So I went to Perl. Perl
I started maintaining the tags on the files. So not only did I have a directory structure
that told me what was going on, but the files themselves I could preserve the metadata
with them. I went from writing my own algorithm for walking the directory tree in due in comparisons
to using Perl's file-fine module. I added support for MP3s because I ended up buying an
iPod. But it grew well. And over time, I threw it out on SVN in Mayo 5. So almost immediately
I didn't subversion. It was on the web. And I think one person I didn't know found it somehow
and started using it. I did a quick little GUI for it. Put it out about January 06. And I
know someone in France used that. He had a problem with it. Which was kind of amazing to me.
These are people I've never heard of. In May 2006, I had it at the point that I realized
I needed to advertise. So I put it up on fresh meat. Which is a great way to advertise
your product and at least get a quick blurb to a lot of people. And so it was there. That
was version 0.9. And by the end of 06, version 1.0 was released. Had a GUI command line worked
really well. And it stayed that way for a long time. I had a lot of goals I wanted to do,
but other projects were interested in me. And then this past Christmas, I had since found
a Python. It sounds religious. And I really like Python. I like the way you code in Python.
And I like the way I think when I'm in Python, it flows very naturally for me. And so this
past Christmas, I spent a couple hours and got to be in Python. It was very rudimentary.
It had a handful of features. But I had started working on Agafi 20. And yesterday, Agafi
20 officially released. I fixed that last lingering bug that was holding it from being released.
And that's where things are right now. So why do you care? I mean, I am, Agafi is really
in the market, frankly. If you're an audiophile and you're big into having lossless codex
and that sort of thing, it makes sense. I refuse to have Agafi convert from MP3 to
COG because a lossy conversion loses even more and sounds really bad. And I've had people
ask for it. And I say, no, it's against the principle of the matter. And there are things
that do that anyways. So I've got 10 points. These are things. I mean, when I started Agafi,
I was still, you know, just generally doing the college programming projects. Nothing
really expansive. I didn't have to deal with people and call it. You know, you have a
homework assignment in school, you know, your lab project. Sure, it might be big, but
you don't have to deal with real people. You have to deal with a piece of paper list of
use cases. Since then, I've gone from that to maintaining this project to knowing that
people actually care about this thing and want to use it. I'm now a C-programmer for
Hewlett Packard working in high availability and clustering. So I'm in a very different
world than what this was written in. And it's given me a lot of perspective and things
that I picked up on which I think are really helpful for if you're starting an open source
project, if you want to get one out to the people. These are points that I think you just
frankly are fundamental. So to start, you need to use version control. Before you even
really start coding, you should be in version control.
When control is great, if you screw up, you can go back and fix it. If you delete something
you didn't mean to, you can go back and get it. It is incredibly worthwhile. And there
are two choices. Central are distributed. If you're coming from CVS or subversion, you've
been using centralized. I don't know about many of the professional open source things
like per force or anything like that. We use clear case at work which, oh, yeah, I'll
end there. And I think the decision can boil down between these two models is subversion
or get. Now, I've used bizarre, I've used material. Those are great too. My preference
is get. The model is what makes me like get more. I pick get out of bizarre material
because I think it's for starters, it's faster. If you notice this last point here ridiculously
fast, it is. You'll be amazed at how fast it is. Otherwise, if you use material or
bizarre, I could care less. If you use something like arch, I kind of care because I still
don't have a clue how to do things like that. Subversion is a great choice. If you want
users to be able to not be scared, get is really intimidating. And I think it doesn't deserve
this reputation, Jason. I've never tried it. The problem I've read about SVK, which is
a distributed layer on top of subversion. So it's distributed using subversion as a file
system basically. If you're using SVK, people can pull out of subversion but they can't
push back into your thing very well.
I will say one thing is subversion support. One five made merging a lot better. Of course,
subversion has a long way to go still. But I've been playing with one five because we're
actually going to switch to it at work from ClearCase, Hallelujah. And it's getting much better.
But still, if you ever do merging and get, you're going to wonder what are these people thinking.
So, yeah, get is really flexible. I think the reason people are scared of get as version control
is because it's like them. If you use them, you realize there's a core set of commands
that really you can get by. If you know how to hit eye and start typing and you can use the
arrow keys for heaven's sake, you can live. But there's the problem is you turn the page and suddenly
you're scared to death because it's talking about doing really weird stuff. And frankly, it's really
powerful and you realize that but you don't have the time to spend to understand. The problem is
is the people who use get or the people who write get or the first people who wrote tutorials
were the people who wrote get. They don't really understand that other people don't think like them
and aren't going to get it right off. After this is done in the Q&A, if you want, I can give a demo
of all the get you ever need to know for subversion users. There's a couple of sites that are actually
worthwhile. Was there a comment? This is related to version control. Version control
is not a backup. You need to have backups. This is a great point. I had two Christmases ago.
I was about to start working on a project for a class, flipped open my trusted laptop and it's
hard drive died. Two weeks later, my VPS had a hard drive fail, which you know it's raid one,
no big deal. It's mirrored. Oh, except for the whole drive array crashed. So all the data was
gone. I had lost everything and I had always thought, oh, it's in subversion. It's on an external
system. That's good enough. I'm backed up. It wasn't. I lost all of Agafice history. I had the most
recent checkout on my machine on one of my machines and that was enough. So remember, you need to have
a backup plan. Right now, I pay VPS provider to backup my whole system with daily snapshots,
which is good and I have it on three or four systems. And the great thing with the distributed
thing, all my history is everywhere I go. No one likes this sort of idea. I mean, I don't know if
you're on a lot of mailing lists. The flame wars will go. I'm thinking of plug and
Lisbon Java come to mind when it comes to flame wars about what's the best language to pick.
Oh, yeah.
Yeah. And this audience has vocal people, too. Yeah. So in any case, I firmly believe that some
languages are better at certain things than others. If you're going to do a project, you need to weigh
really the important matters. What libraries do you need? What are you going to use? What are
you good at? I mean, if you're an expert in Lisbon, you should, if you're not expecting to need
20 people to work on this with you. Lisbon is great. I mean, or really ambitious college kids who
just learned it. The community around the language can matter a lot. I mean, if you want to use this
weird feature of Ruby, but only three people on the planet ever use it, it's going to get a little
iffy sometimes. So for Augify, because I really care about my audio metadata, this would be an
example of what I'd consider between Pearl Python and Ruby. So Pearl has audio taglib, taglibs of
C++ library. This is the wrapper for it. It's available in Debian and Cpan, of course, but I'm
not counting Cpan. I'm trying to keep it to the easiest method available. Most people consider
if it's not in the package manager, it doesn't exist. So it was in Debian. That's great. It only worked
in Linux, except for that OS X patch that only kind of sort of worked most of the time that I hosted.
Ruby has a single library per format, which is a big pain. No one distributes Ruby libraries. You
have to use Ruby Gems, and I'm frustrated with Ruby Gems most of the time, but it's everywhere.
They're all pure Ruby, so no compiling, no cross-platform issues. Python has one library for every
format on the planet. Medigin. Great. Every distro has it because all the Python media players,
which there's a number now, depend on it. So they all ship with it, and it runs on every platform,
even Windows. This was an awesome, this was a bonus for going with Python for me.
You might not be able to read that, but it says the bunny loved the scarf, but didn't know what
to do with Sonic screwdriver. If you've ever watched Doctor Who, the Sonic screwdriver,
yeah, it is the solution for every problem. I'm told to overuse that back in the day a little
more than they do now, but you know, it solves everything. And just like that, you need to know your
tools. You need to know how to use them and make the best advantage of them. So to start with,
I just want to give an example of what my like, this is, I code and see at work. So I have my VIM
environment tricked out for C. So I don't, I mean, I can't bring company source code to show you
something hideously complex, but you know, this is frankly a big files, 300 some odd lines,
you can't see everything at once. So I've got an example function being called a couple times.
What does it do? Oh, there it is, you know, controlled by bracket, found it right away.
If I want to know who finds it, using C-Scope, I can do reverse lookups. C-Tags does the other
direction. Using these two tools makes my life so much better, because if I need to figure out
where this function defined, who calls this function, who uses this variable? I never leave VIM.
This speeds up my work because I don't have to switch over to using my browser to search through
the code or go into Google. If I'm curious, let's say, I forget some of the printf switches,
Shift K, except for if this one brings up the wrong printf. So, no, tap around. Oh, there's
the printf man page in my VIM session and my VIM window is usually much bigger than this, so this
works wonderfully. I want to compile, oh, color make. Oh, there it goes, it's built.
But let's say I want to, you know, we'll break things for a second. Oh, there's an annoying error,
and you know when you're working with big code bases, this is a huge pain. Well, VIM, when you use
colon make, detects that error, and pops me right to the line where it is. I do colon C next,
and I go to the next one. And so it makes a really easy way for me to do everything I need to do in
my day, all in VIM. And this saves me tons of time. To give you an idea of my VIM RC, which I'll
post in this tarval of all these example files, is about 100 lines. So everything I've customized
is about 100 lines. I know people who are much more heavy what users VIM than I am. My shell,
which I consider really important, I have a pretty customized DSHRC. I need it because while I'm
in the shell, I need to get around, I need to run things quickly. So I've aliased everything I have
to rebuild my C-tags and my C-scope, single aliased, rebuilds it for a 250 meg source tree that I use
at work. My teammates are a mix, there's a handful of us doing Linux, but most everyone is developing
an HPUX. And yeah, I actually have a couple of co-workers who do working Eclipse, which is really
interesting, the amount of effort you have to do to, you know, since we're in clear case, so we
have to be in HPUX to check in and check out. And yeah, we have a lot of extra wrappers to make
our lives work right. Subversion will be wonderful. So we all know there are good ways to code and
bad ways to code. If you use Python, they're really strict about the good ways to code. If you use
Perl, yeah. So in any case, you need to at least be standardized in how you do what you do.
If you look at the good projects, I think all either have a standard, like the Linux kernel,
it has a very strict coding standard. Because a year later, if you look at your code,
unless you have a much better memory than me, there are parts of my code I forget about. Three
years old later, it happens. If I look at someone else's code, I've seen a mix of these where it's
really, really good. The Django project has some of the best source code I've read, and there are other
projects that I cringe to think of it. Have you ever looked at the source code for Ping? You'd think
Ping would be really easy, right? Ping is terrible. It is one of the worst pieces of source code I've
ever looked at. Actually, that whole tool's utility, the way he wrote it, it's like function pointer
heaven. Frankly, it's way more complex than it needs to be, and I don't know how anyone maintains
this code. Just to give you an example of why I think following the rules is great is I've got a
couple of Perl examples here. They all do the same thing, which is great. Isn't that nice?
So let's look at what I call the good version. You could take five minutes and other than the
joins, which I think might throw some people off, this makes pretty good sense. I mean, even has an
out of loop print. That makes everything easier. Then there's the bad version of this. I'm not sure
how this works. Mind you, it is two lines. This is a terrible Perl golf competition, because look,
he statically defines the string. Come on. What sort of person does that? Here's the best version of this.
Yeah, I do what this was doing when I looked at it. I love that. This is a great example of
Perl golf. I'm told this implements RSA. No, I did how? It pops it through DC, though, which
scares me in so many ways. DC, of course, is RP and calculator with way more capability than any
calculator should have. There's obviously more than one way to do it in Perl, but some of those
were just not the best way to do it. Ruby has the same sort of thing. In Ruby, we have actually,
they're fairly loose on their standards, but for example, this works. It prints out some numbers.
If you're a Ruby guy, you should notice something that really upsets you, and it's this.
This is terrible Ruby, as far as Ruby people are concerned, and I can't tell you.
The ending bracket, because it should be a due end if it's multi-line.
Brakets are great for do loops, if it's one line, but for multi-line, you're supposed to use due end,
because it's much more readable, much more consistent with everything else.
That's just a case of good standards. Bad Python's harder to spot, because it usually means you're
using real tabs and Dev spaces in your indents and upsetting people. It's true. There's a reason,
run Python with a dash TT. It'll complain if you mix real tabs and spaces. It's great.
So here are links to various community standards. Python, it's an official documented thing. Perl
has actually a PerlDoc page on it, and by naming Conway's book, at least you'll tell you how to
maintain a style. This was the only thing I could find for Ruby on the first page of Google. I
didn't look any deeper. Like I said, the limits kernel is actually a great standard. The K&R,
for C, has a good standard of code, which is mostly what we use at work when people remember to.
Yet, enforcement's really nice too. Perl has Perl tidy, which will enforce a style.
Well, worth it. This is the best thing I've ever learned.
Literally, I mean, some people are huge on this whole refactoring thing, and this is
driving the whole refactoring thing. When I started Agatha, I wrote my own algorithm for
walking down a directory tree and walking down another and comparing the differences.
Well, I did that really poorly. It was really bad. Poor performance. A friend of mine was like,
well, why don't you do it recursively? And he gave me an idea, and I went with that, and
probably ten times as fast. But it's still my own code. And then I used file find in Perl,
and it was probably ten, fifty times faster. And suddenly I didn't have three, you know,
a hundred lines of Perl to maintain to keep that working.
Oh, stop, path down. Which one's the one that's iterative?
Yeah. So actually, that comes up later. There's fun between the two of them.
But, you know, because I was willing, once I got over the fact that, yes, I did write this code.
Yes, it's my baby. Who cares? Throw it out the window. You know, throw the baby out with the
bath water sometimes. That was terrible. But, you know, it was really worthwhile. And sometimes it
takes that gutting of the program and redoing an entire part to make the changes you need,
like improving your modularity, your performance, the simplicity of your code. The first time you do
it is not the best time you're going to do it. The third or fourth try, you might be getting somewhere
worthwhile. I don't think I need to say anything here. Does anyone in here not write tests when they
code? Yeah. Well, Agile is starting to pick up a lot in Agile. So, from what I understand,
I'm not an actual Agile programmer, but you write the test, then you write the code.
That last bug that I had to fix? This is the test case for Agify. To verify, I never,
break this. You know, it's great. I wrote the test case. I ran it. Oh, it failed. I fixed the bug.
I ran it. It works. Does everything I wanted to do and I will never make this mistake again.
This is a little Agify centric, of course. So, I don't expect to understand it. Basically,
not empty directories were being deleted. Well, actually, they weren't because Python's smart
enough, but they're throwing exceptions, which killed everything. That's bad. And I didn't want to
catch the exception because there's actually other reasons to fail deleting the directory that you
want to crash. So, and they're all the same exception is kind of dumb. So, anyhow, this is my good
reason for tests. You don't break anything. You did it at the first time. You don't make it again.
The mistake again. I didn't start writing tests for Agify until late into the pearl life,
or late into my pearl life cycle. It was a hacky shell script. It wasn't stable, barely worked.
Now I'm using Python's unit tests. It's so much better.
Yeah. And for all the basic cases, Agify are now covered. Agify is pretty straightforward,
frankly. It takes a little bit to work out the fact that I'm having to compare directory trees
and stuff like that. So, there's a lot of support code to even have my test work well. But once it
was there, I can write test cases like that. Now, if you were in the Django community about a year,
year and a half ago, there was a group of people who complained that Django kept that Django was a
not invented here group. They had a lot of libraries that were in the Django code base that
someone else was doing. So, why are you maintaining your own? When people didn't realize Django had been
around for about two years before it was open sourced. So, when these people wrote their code,
it didn't exist otherwise. But you should not do this. If someone else has written the code, use it.
I firmly believe whatever code you write is part of what you're trying to solve. And that
complex tasks are never a good side project because that's what backup libraries are. You know,
the libraries that support you are always going to be side projects to your main goal.
For example, I was in security class, had to implement the AES algorithm, Rindall.
The worst part of it was the finite fields arithmetic, which is really supporting to the main
part of the algorithm. I spent way too long on that. But of course, there was college we couldn't
actually use someone else's library kind of sucked. Don't re-implement cryptography ever. Use
open SSL. It doesn't write unless you're Debian. And then it does it wrong. But you won't know that.
And so, this last, this is kind of the conceptual part from here on out. This isn't very much about
coding. You need to, when I started to agify, it was a hack. Hacks are great for small tasks. But once
you get bigger, and especially once you have a semblance of a life and you're not in college,
just, you know, sloughing off your programming projects that you get grades for,
you need to know where you're going to end up. Know what the goal of your program is.
If only so you can plan and say, I've got three hours on Saturday I can code. I can do this.
And that makes life a lot easier to manage. Frankly, my lack of doing this is the reason why
agify tends to be, I had everything working in about May and I released in August.
The doing agify over again in Python, I knew where I was going. And I could really think about
what I wanted to do. And it's really important, I think, to consider how you want to build something
in code. Like, agify is actually an MVC program. So the command that you're running is calling
libraries. It does almost nothing, which is great. It means I can make a GUI for agify and it'll
be trivial. It means I can support it much easier. It actually means I can test it easily.
There's lots of design patterns out there. If you have one you like, use it. Consider how to use it.
Consider do you want someone else to use your code? Do you want to use your code somewhere else?
Think about those algorithms, classes and data structures. Until you're designing an interface
and this does apply for the command line. A GUI people don't think the command line takes design,
I think it does. A great common I read about design when it comes to interface design is you
can't think like a programmer anymore. You need to step away from the computer. I actually do
design in notebook by hand for whatever it is because then I'm not thinking about how is this
code going to work? Your interface should never be driven by code. This is the quintessential reason why.
The comic, not the comic, this. If I go up to the toaster and I want a piece of toast,
I put toast in, I push it down. The minimum number of inputs and the default action to run should
work. It should not stab me in the face with a knife. That is I think one of the best pieces of
commentary on the way some people design their interfaces in the open source community, especially
on the command line. Yes, all but two of my images are xkcd. I like xkcd and it applies so well.
You know, I'll get five. One of my best compliments I ever heard was it has the best default
that person I'd ever seen. If you plunk down and you run agify, you say, where are my flat files?
Where do I want my ag files to go? It works. Nothing else was needed. If you want to do mp3s,
you have to throw in an argument. But it just works out of the box. If you use things like
mplayer, which is a 50-50 chance of working out of the box, maybe if you're lucky, if your
distribution has tweaked your defaults to actually use also. Yeah, yeah, we won't get into it,
life. You know, there's so many programs in Linux that don't get this. The GUIs are cluttered,
they're hard to use. You can't figure out what you need to do to get it to do what it's supposed to do.
The better, if you really think about interface design, your user is dumb and he's going to run it
before he ever checks the helper the man page. I'm sure we all do the same thing. I played with
Transformers as a kid. I prided myself in not reading the instructions on how to get those things
changed. And they didn't make those very easy. And I'm sure we all have that mindset. I mean,
LEGOs were a different story. They're a little harder. I can't look at a picture and go LEGO set,
but none of us like reading instructions.
I overheard someone talking the other day that they had something they wanted to open source,
except they were trying to clean up those last few comments. They were trying to fix
you know, the little pieces here and there, get the documentation up to snuff. No one cares about
your documentation. Well, no one cares about your documentation until you have released. A head of
time, it's useless. You know your code. You don't need it. It's good to document while you code,
but the minute your code does what it's supposed to do. So your main feature. So when Agify could
take a source tree and create a destination tree, I put it out there. That was working. It couldn't
retake files based on timestamps. It couldn't re-encode based on timestamps. All of the extra features
that make Agify, I think, really useful didn't exist. But once it was out there, I got test results
from people who weren't me who were trying to do things with it I didn't think of. Once you get,
I mean, if you're doing a library, it's going to be hard. Your first few adopters are going to have
to read through your source code and figure out what each function does. And if you're worried about
that's going to hurt your adoption rate, don't be worried because the people who are going to use
your code right away are going to read through your code anyways. It's just that the early adopters
are the type who don't care about the obstacles. They want what you're providing and will do anything
to get it. And like Howard talked about today, you know, those number one fans, your first users are
always going to be your number one fans because they were the ones who didn't care. They wanted your
functionality. They didn't care about your prettiness or your ease to use or your documentation.
Augified didn't have a man page until this recent release because it had a really good
dash help and I don't want to ride in trough all day.
So,
well, it's not, but I love this picture. It's by far one of the cutest things ever.
Yeah. It's a rabbit, not a cat. I realize, but it's irresistible.
Yeah, I looked at this one for like three days straight because I thought it's just that stupid
annoying extra cute factor. So, hit me with your best shot. Whatever questions you have,
my thoughts on things, any of the topics we've just covered, or if you want me to give a run
through get, I can do that too.
I went to a presentation by Hans Fugel a few years ago. Hans is a Vimnerd.
And that helped really well. Sadly he's in New Mexico now, which doesn't help us.
But nowadays, I read through the help a lot. There's actually an abbreviated list of every single function
that you can get in one single help file. I don't remember it's called, but if you get dig
around for a couple of minutes, you'll find it. Yeah.
Wait, what was that? I can't quite read.
I don't know him. Frankly, I just used the library. I actually have a wrapper around the library
so I can use MP3s in the same way I use OGS. I should probably contribute that back. It's kind of handy.
Oh, yeah, the Debian comments while back. Yeah, you know, frankly, every time I hear Debian
doing something like that, I roll my eyes because frankly, some of the Debian people are that too.
I'm sorry, but Ice Weasel is the dumbest thing ever.
That was when I was like, yeah, Debian is just on my server, not my desktop. I'm sorry.
Well, there's opinionated people on both sides of the argument. Maybe in that one,
it's more him than the maintainers. And I thought the comment was hilarious. I actually read
that whole bug track page. I laughed for a good 20 minutes on that. But you know what? He
provides a good library. So if someone added a comment to, I think it was the package for either
mutagen or what's his thing on top of it. Yeah, and it was like a test case or something like that
that was blah, blah, blah is the day. I forget his name. His name. And so he put in a bug about that
saying this was, you know, terrible. Yeah, there's something like that. It was hilarious.
Yeah, I don't frankly interface it all with mutagen, which I've done enough with it. I probably
should. I probably, like, especially since, you know, MP3s are a pain because they're so well
structured versus like, organ, flat, which are unstructured. I wrote a lap, a wrapper library that
lets me use both in the same interface. ID3 tags are one of the most structured, finely defined
metadata you will ever see. It's scary. I've actually implemented ID3 myself before. And it's
detailed. I mean, every single tag is so specific on what you can put in. There's so much,
it's very heavy weight. And so when you work with it in mutagen by default, you have to know you're
working with MP3s. Everything else is just like a, it's a dictionary. Here's a key. Here's a
value. Here's a key. Here's a value. They don't care how many times you use the key. They don't
care what the key is formatted like. MP3, the key is one of these, sort of a four-letter combinations
and must be, or it's a comment. And so I wrote a wrapper to make it so everything was just
a dictionary. It's great. I should contribute that back. But I play Z. What can I say?
Oh well.
Oh well. Yeah.
You know, it's, it's one of those cases where someone who maybe, you know, you get those really
strong personalities sometime. They might make the best thing ever. But I mean, Linus for heaven's
sake, you read Linus' comments and he is not nice. He gets away with it, but he's not exactly a
friendly guy. Yeah, I mentioned Ryzer, but that seems like taboo these days to talk about Ryzer.
But yeah, Ryzer, frankly, it's a jerk too.
Yeah, exactly. It's a little taboo, but frankly, I knew people who had talked to Ryzer in person
and asked, this has always been broken. Why don't you fix it? And he's like, no, that's stupid.
You're wrong. It's like, that's really helpful. Yeah, whatever.
Anything else?
Um, do you have any field for health-based community around the audience?
Um, I really spoke with people that can contribute back and also people that use it.
So I've got one guy, Gerald Cox. Never met him in my life. He is my frontline for bug reporting.
He packaged version 1.0 up for DAG's repository, so you could get it in Fedora.
He is easily my, you know, number one user. Then I have a handful of people who I personally know
who give me bug reports. I've never gotten code back, which for the size of the project, I don't care.
I've got your feature requests. Back when I was doing the Agify 1.0, and I was tracking, you know,
I was doing serious web stats tracking for some strange reason for as few hits as I get.
Apparently, there's an open source software hosting site in Brazil, and Agify gets a lot of
downloads in Brazil. Never heard from these people, but it's more than I'd expect. It was like,
it was probably something like 20 a month, maybe 50 a month, but it was still shocking.
I mean, especially since the early versions of Agify had real issues when it came to non-latent
one-character set data. Now it's in mutagens, and it was all the metadata. Mutagen does everything
in unicode. That is now over. But yeah, early versions of Agify were not very friendly to that,
so I was floored when I found that. I was getting something like 200 hits a month from Brazil,
just from that site, pulling, and they were hot-linking my tarball, and I don't care.
So, yeah, the community isn't exactly rich. It's kind of a niche thing. I don't really advertise
very well. This is probably one of the better moments of advertising I've had.
At the moment, for a source, we only support Flack at the moment. Output to Augs and MP3s,
various modes of MP3 as well. But one of the benefits of rewriting and Python,
or of this of rewriting it, is it now has a plug-in framework. So whether someone else wants to
contribute a new codec that it supports or asks me to support it, I need a minimal set of information,
like for a new source. I just need to know how to make that source into a wave file. That's really
all I need, and preferably dump it to standard out. For an output, I need like a little more,
but not much. So now it's really easy for me to add formats. I'm planning to add Apple
lossless as a source and destination so you can go between lossless formats. MP4 is on my list of
things to do because it is better than MP3, at least in compression to quality and stuff like that,
and it's not nearly as patent-encumbered. It still is, but not as bad.
At the moment, I'm actually working on a audio-tag editor. Is my goal because I think all audio
take editors that exist today suck? Yes. Easy tag is easily the most powerful one I've used,
but it's not easy. I'm very confused by their name. If you use easy tag, it is
mind-numbing how badly designed it is. That's my next goal.
It's still going to be toolkit. I'm actually going to use Coco for OS10. I'm learning
the Python Objective-C bindings right now, and then I'll just do GTK2 for Linux,
because frankly, I looked at the cross-platform toolkits, and
unless you're in Ruby using shoes, which is easily the coolest thing ever for GUIs,
and I'm not going to code in Ruby. Sorry, not for that much. I do Ruby at work for some stuff.
Ruby is great. I actually think they're doing a great job, but I really like the back-end
setup I have here for tag editing, so I don't see why I want to leave that.
I figure if I write the code well, it should be easy to move the front end.
It's kind of off-topics for your presentation, but seeing an audio person,
you are, is there an online door of some nature that you could actually recommend for high-quality,
legally purchased Linux, or is there pretty much none that you'd recommend that far?
Go to flack.sf.net. They actually have links to music stores that provide flags.
The Philadelphia Symphony provides recordings of their concerts and flack for purchase.
There's three or four others that provide flack as an option. Obviously, the all of MP3,
I don't know if they've installed this, they provided flack, and since they were a
per megabyte purchase price, it worked really well for them. But yeah, flack is actually
fairly, there's a couple of indie record labels that provide flack downloads.
There's one or two slightly larger sites that provide flack as well. It's getting better.
But still not great. Frankly, I'm actually pretty, I'm pretty pleased now that even the lossy,
like Amazon MP3s are fairly highly bit rate encoded. iTunes, if you use iTunes Plus, the DRM-free
ones, which are the only ones you should ever buy, are actually at twice the bit rate as they're
standard, or it's at 256 on an MP4, that's actually pretty nice. It's not great, but we're getting
there. Amazon is encoding at 256. Yeah, 256 VR. And, you know, I don't have speakers that can
compete, that I can tell that is a problem. I had speakers that I could tell 128 MP3s were a problem.
Amazon does watermark at least some of their MP3s, but it's a global watermark. It's not
for customers. It's actually really easy to undo, too. I think it's just a tag in the file.
I saw somebody that discovered that they modified the audio. Oh, really. Interesting. Yeah.
They probably want to be able to gather statistics on how much people are buying Amazon
tracks and then file sharing them. Because they probably need to report, have to report to the
record companies. Yeah, we're DRM-free, but look how few people actually distribute these illegally.
Yeah. Apple does fingerprint theirs as well, but it's per customer and it's actually a tag in
the audio file, which when I make an audio editor, we'll have an option to strip. It's pretty easy, too.
I'm not aware if they do or don't on their DRM-free tracks. They do put actually, but they put
customer-specific information in the tag, so it may not be watermarked, but yeah. It's easy to
track you down. How much time do you spend on audio files? These days, it's very based on how heavy
things are at work, because if work has been really heavy, I don't want to touch a computer when I
come home, which is kind of annoying in a lot of ways, but it's out goes. So, Agify ranges from
I plunk it an hour to a week to I've had weeks where I'll put in 10 to 20 hours. It's very
variable, which is why I don't produce consistent release schedules, or even very good consistent
plans. Like, the next step obviously is get more audio format support, and I'm not going to say
when that's going to happen, because I don't know. So, if there aren't any other questions,
that's all I have, unless someone wants to see me play around with get for five minutes.
Agify is in get. All of my personal stuff ends up in get. Yeah, no. Everything is in get.
If you go to get.scotr.org, you can see my wonderful web version of get.
I actually my blog is rich in in Django. It's open source because I'm too lazy. It's not under
any specific license, because I'm really lazy with that. We can assume it's public domain at this
point. You know, it's it's unlicensed code city on the internet. What else am I going to call it?
I'm not even sure I have a copyright statement on it, but I don't care. It's a blog in Django.
There's like 20. I actually get a lot of feedback for that because I have about four friends who
use it. So, I've got in a couple of patches for it. So, get in like five minutes.
I've got this new thing, and I've got a file in it to start it. Get in it. Not very hard.
I think the hardest thing about get to learn is add is for more than when you just add a new file.
It's for whenever you change a file. For every commit, you either have to explicitly add or
tell commit to add everything that's changed. I always run commit in that way. So, in this case,
I added my first file. I do get commit.m. There I go. If I edit this file,
yeah, because I added it earlier. So, if we do get status, which does just what you think it is,
you can see I've modified high, but no changes added to the commit. So, in get, when you run commit,
if you want to do a more subversion like workflow, just add a dash a. Adds all the modified files.
That will not add any new files. One thing that's great about this is, let's say, for some reason,
you've checked in the configuration file that is system-specific, that you don't want to have in
your repository. Get RM will take it out of version control, but not to delete it. Which can be
handy in a lot of cases. And if you RM a file, I can't remember if it tracks that or if it needs.
I think you then have to manually do a get RM after that. So,
just to do an empty get commit, it says, well, I can't. There's nothing there,
but get commit dash a. Yeah, that's the trickiest thing I think there is in get to get used to it first.
It's just because I modified it, does not mean it's going to be committed.
So, I'm here. Yeah.
No, once you, so it's per commit. So, if I had it a file three times before I commit, I need to add it once.
But yeah, so get commit dash a. Most people, I think, are going to work in this sort of mindset.
So, what if you edit the file, add it, don't commit and edit it again. You don't have to read it.
So, get is in a state where it says, okay, I have committed here and we're working.
Once you hit add, until you commit again, that flag is marked.
I want to put this on my server. So,
I tell it where to push it up to.
Oh, yeah, it's not there. That makes things hard to push.
There's a flag to do it, but I always forget how. So, to copy a get directory and all that
that's history is get clone. And I can just say, so I create new to, new to has the file.
I put new to up on my server and I forget the dash R because I'm stupid.
All the fun gets stuff goes up. There's actually a better way to do this. This is not the preferred way to push.
What do you do is you do a get clone dash dash bear, which only takes the metadata rather than the
live files. That's what you put up online for people to clone from.
Yep. Actually, you can create one by just deleting all your files and having a dock get directory.
Actually, it's by taking the dock get directory and pulling it up the level.
So, I'm cloning remotely here. I actually always do this after I push up a copy because
in new three, if I do a get push, it knows where to push it to because it goes to where I got
cloned it from. You can manually edit this in the get config file, but I still don't understand
what this line means. And so, I prefer get to do it to set that up on its own. That's some of the
get magic. What? Yeah. So, I just don't think about it. So, if I clone from a remote repository,
the origin, so where it pushes to, is where I've cloned it from. Which is handy? Get pull is just
like an espion update. Grab the changes from upstream. You can specify URL and tons of voodoo
magic stuff. That doesn't give me any output. This is a fun thing. Download objects and refs from
another repository. Yeah. Pull does apply it. Yeah. Pull does everything. Merge. So, if there's
upstream changes, pull will try to apply them right off. Yeah. And so, what I use get, I'm still
coming from kind of a subversion mindset. So, for me, I use get cloned to create copies, get push
and pull, put things up, get commit. And that's get. Get is really cool when you, yeah, I mean,
that's how I use it. Now, I just created a branch right there. It's local. And, you know,
subversion has the whole file system mucking about with naming and conventions and crap. And,
now, I just did that. Let's check out. Is that switch?
And subversion? Branch doesn't switch you to the branch. Yeah. Yeah. So,
so get branch new and then I'm not in that branch. So, I do get checkout new. That's kind of
weird for a subversion user. I think I wish they had named it switch, but whatever. So, if I'm in
the branch, I make more changes. And I don't know why this. Okay.
Oh, yes.
Why is get commit dash a not working?
Now, I don't know why, but it was untracked. Weird. So, I can do
and I think it's what's get merged from a branch. Oh, get merge in the branch name.
Yeah. This just did it. And so, branching and get is easily the most powerful thing. So,
when I was doing Agify, there's OS.walk and OS.path.walk for doing directory tree walking.
The difference is one is iterative and one is recursive calling functions you provide.
recursive calling functions you provide gives you that cool. It's like list feeling.
And I wanted to see which one was better. Like seriously, which one would be faster and more
efficient. So, I wrote up one and then I created a quick branch, switched to it, wrote up the other,
and I switched between the two to see which one was performed better. It turns out OS.walk,
iterative one. The one you're supposed to use is a magnitude, an order of magnitude faster than
the other one. They use the same underlying structure, but something about not having to create
new stack frames, I think helps. Go figure. Yeah. Well, that's a function called tends to be a stack
frame. It's not one to one I know on Python, but you think like that it helps, at least me.
So, that's the get in five minutes and why you should use a bonus presentation.
But yeah, it's, I'll actually post up on my blog tonight. I'm in the Utah open source
planet. Link to a great thing called, I think the site's called get magic and they try to present
get in a way that will not scare you today. And then she do really well. He doesn't present
some things in the best way ever, but for the most part, it gets across this and starts getting
you into the scary, weird, trippy stuff. More easily. That's all I've got.
We'd like to thank Scott Robertson again for his two presentations,
what he learned from logify and a crash course on get. And also the room sponsor guru labs or
website is gurulabs.com. We have some surveys on the table in the back corner. If you'd like to
leave some feedback, thank you again. And thank you, Scott again.
Thank you for listening to Acro Public Radio. HPR is sponsored by Pharaoh.net.
So head on over to C-A-R-O dot N-E-C for all of those meetings.