Squash 1.0

Sorry for the delays everyone. I think my host (savannah.gnu.org) finally got their act together and fixed most of their hosting problems. That was a month ago. It took me that long to get up off my butt and then figure out how to use their new distribution system (which is, by the way, worse).

So 1.0 is out. I haven't been too concerned about releasing it (sorry) because I was busy petting my deprived picture collection. (I settled on using the php-based gallery software on sourceforge). I haven't finished sorting my pictures by a long shot, but at least I've got it better than it was before.

But back to the subject: Squash 1.0 primarily represents an adequate port to the empeg. It's not perfect (the most annoying thing to me is that getting to the next song takes about 0.5-1.0 seconds), but it's the best that can be done for right now.

I do plan on giving Squash my attention again eventually, but I'm not sure exactly when. I will be effectively rewritting it, not completely, but I will at least be ripping the guts out and replacing the threads with something else -- the threads right now are my biggest gripe, programmatically speaking.

For those that don't know, and I should have probably put this at the beginning of the post, Squash is a replacement player. The most important differences is the support of OGG, MP3 -and- FLAC. Also, an easy to use and open database format can be used to store both the meta information (such as artist names) and also for storing play preferences.

That brings me the biggest thing about Squash, the player is fully automatic. That is, Squash will monitor your playing habits and pick songs for you. You don't have to do anything except skip songs you don't like. You -can- even rate them manually if you are so inclined (though, I'd probably advise you do so ahead of time, not while the song is playing).

Automatically picking songs is Squash's neatest feature, but also (at the moment) it's biggest liability. Right now, there is -no- way to pick a particular song or even group of songs you'd like to play (actually you could hack something out through the hijack menus, but you'd be a lunatic). These features are inheirently secondary on the list of things to do for me because of the nature of Squash.

But I will be adding them, I just couldn't do it for the 1.0 release.

Anyway, I hope things are found to be relatively stable. I have had the program lock up very occasionally, but I have never had any corruption of the disk or anything of that sort (some have been ansy about the fact that squash runs in rw-mode, in order to save your listening preference).

So check it out:

http://freshmeat.net/projects/squash/

I haven't uploaded all the files I used to have on savannah, but at the moment (at least), they are available here (1.0 is not here):

ftp://ftp.gnu.org/savannah/files/squash

I tried to upload a notice to this effect to my official area, but it's been constantly failing to oblige me.

Anyway, as always, a long-winded post by yours truely:

Adam Luter (Gryn)

Take Care!

The most important differences is the support of OGG, MP3 -and- FLAC.

Umm. The alpha releases of the v3 player support Ogg, MP3 and FLAC...

Well they still have an "alpha" tag. I get to boast a "1.0" tag.

Anyway I like the learning shuffle and open database best. The support for extra formats is more of a base-line requirement than a feature you can pat yourself on the back for.

I wonder whether gapless playback, intelligent cache strategy, cross fading and advanced visualisations fall into the base line or the back patting category

Rob

Everyone has a different agenda of course!

I get to boast a "1.0" tag.

Ummm...they have an "alpha" tag while you have a "1.0" tag because they don't consider things like "very occasionally locking up" and "no way to pick a song manually" to be features worthy of a "1.0" release; they consider them problems, not something to brag about.

The support for extra formats is more of a base-line requirement than a feature you can pat yourself on the back for.

Agreed. Hence, you may want to reconsider the "1.0" tag.

"no way to pick a song manually"

FWIW, this feature -- the automatic on-the-fly A/B/C-list playlist thing -- has been on my personal wishlist for years. It's the only thing which none of my various Rio gadgets can do but which the thing I used before I joined Empeg (mserv) can.

Peter

It would be nice.

Honestly, other than the burning desire to have kanji/kana capability on the empeg, I don't really have any great feature add/change wishes at the moment. Pipe dreams, yes. (hi-res color TFT, etc.)

And to be honest, my Nitrus has even helped to distract me from the yearning for the kanji/kana display on the empeg. Works beautifully with all the japanese tracks I've tried on it so far. Kudos to all involved!

Wow, everyone that's taken an interest in my player (on this thread at least) has seemingly taken Squash as some sort of hostile play, or at least some sort of arrogant attempt.

I don't have anything against the native player. I just like to listen to music alot differently than most people (it seems). So not being able to pick individual songs -really- and -honestly- doesn't seem like a big deal to -me-. I understand others that would, but with regards to my personal taste, it doesn't show up on my radar.

Squash was meant to help manage your music for you in a automatic way. When you have more than even 3,000 songs (and I'm on my way to almost 20,000) it is, at least to me, a pain in the butt to try to create playlists and pick what you want to listen to.

But anyway, I didn't expect so much aggression. And the lockups I mention are from the threaded design, which is probably an incapacity of my part, but the threads are a real B-word. That's why I'm going to tear down that scaffolding and try what I believe to be a more managable approach that will rely alot less on threads.

I hope people can at least take some of my -good- ideas and use them to make things better for them. If that means actually running my rickety player, great. If it means they get integrated in the mainstream player, probably even better! But at the least, I would think I'm not -hurting- people/things by having an alternative. The mood in this thread makes me think so.

And the only other point I'd like to mention is that I would hope no one expects me to make a player anything of the quality you find in the main player. Do I look like a professional -team- of systems architects and kernel hackers? Nope, I'm just a single, simple programmer. Squash is one of the largest projects I've ever made, and there is only so much a single person can write. But anyway, I hope someone will enjoy it, if not, I will at least. So I guess a good raspberry to those that don't like me:

Of course, I may just be paranoid, it's always easy to get the wrong impressions over written media. So let's give peas a chance .

-Adam Luter (Gryn)

> Wow, everyone that's taken an interest in my player (on this thread at least) has seemingly taken Squash as some sort of hostile play, or at least some sort of arrogant attempt.

I thought the same thing, and I found it kind of odd. Usually everyone is so complimentary around here about new projects like this. Well, I say keep it up! Eventually the Empeg guys are going to have to stop working on the car player, and you will have plenty of time to catch up and maybe even surpass it.

I may just be paranoid

Just because you're Paranoid doesn't mean they're not out to get you I for one think its great that there is at least one alternate player out there that is seeing some active development, and the auto picking of songs thing seems like a very cool feature (my player is on random 95% of the time anyway). I've been meaning to give squash (but not squashed peas) a try on my backup player for a while.

-Mike

Hey, once you've got the 1.0 files up somewhere with linux-newbie-grade empeg installation instructions clearly linked, let me know, and I'll make sure Squash is referenced in a couple of places in the FAQ.

Sheesh guys! Lay off, will ya!

This is one person, producing incredible software for our favourite machines -- that might be just the diversity we need in the long run to keep our players via ble.

What's with all the negative karma here?

Cheers

What's with all the negative karma here?

Nice pun.

In my opinion (and I stayed out of this thread initially because of this), Adam originally brought the negativity with his comments that suggested the empeg guys were patting themselves on the back for having FLAC, Ogg, etc. support. I think I understand what he was trying to say, but he should probably have found a better way to say it. When such a comment is made in the thread announcing the 1.0 release of your 3rd party music player, it's bound to leave a bad taste.

Getting back to Squash, I actually played with a couple of the prereleases, and found it to be a very novel approach. I think automatic learning of listening patterns is the future of music players, and the algorithms used by Squash are certainly going to do a better job of picking your favorite tunes than a purely random shuffle. That being said, it falls short of the empeg player in many areas that are important to a lot of users (including myself.)

So, the question then becomes... Would it be easier to augment Squash in ways that would make it as user-friendly and full-featured as the empeg player, or to take Squash's primary asset (the music selection logic) and integrate it into the empeg player? The former is surely the larger task in terms of man-hours, whereas the latter would be yet another drain on the precious little empeg-hacking effort that the Cambridge boys can give us.

Of course, the benefits of having our own open source player would be great, but I'm pretty darn happy with the empeg player as it is, and anything I haven't been happy with I've been able to find ways to hack around. I don't know how much more advanced Squash's algorithm is beyond what's already available in empeg custom shuffle modes, but maybe we can all discuss that here, and generate some specific ideas about how to improve the intelligence and utility of the empeg player's shuffle modes. If it becomes clear that Squash is far and away the winner in the "DJ In a Box" category, then maybe it's worth considering how we'd approach the task of further developing Squash into a player that could compete with the empeg as an everyday player app.

Adam originally brought the negativity with his comments that suggested the empeg guys were patting themselves on the back for having FLAC, Ogg, etc. support. I think I understand what he was trying to say, but he should probably have found a better way to say it.

My thoughts exactly. If anyone read my reply as hostile, they misread it. My point was that it is not the wisest idea to start out by noting that many features on your software aren't working, then thumb your nose at the people who CREATED them empeg by pointing out that you have a 1.0 release (which I feel is arbitrary given the status stated by the author himself) while they have "only an alpha release".

Don't get me wrong; I agree that the layer learning what I'm in the mood for at any given time (and in general) is a phenominal idea. Sheer brilliance. I applaud Adam, both for the idea and for the work he's put in. But I still think he was out of line with the comment about the Cambridge guys only having an alpha, especially given the fact that they're doing this out of the goodness of their hearts.

I hope Squash does well, and becomes another asset for empeg owners everywhere.

Of course, the benefits of having our own open source player would be great, but I'm pretty darn happy with the empeg player as it is, and anything I haven't been happy with I've been able to find ways to hack around.

Not to put down squash, which I haven't tried yet and thus cannot comment on, but we already had one called rioplay, yes?

So let's give peas a chance

I could get on board with corn, but there's no way I'm giving peas a chance.

My dry comment about gapless playback and cross fading was a tongue in cheek response to your dry comment about vorbis and flac - 15 all and no hard feelings

Rob

Hmm, I can't seem to get squash to start. When I try to run it I get "Can't create '~/.squash_control'". I am sure that both the root filesystem and hda4 are mounted read-write and I can create a file in that location by hand. Any idea what the problem may be?

-Mike

Can't create '~/.squash_control'

Nevermind. I think there is a bug in your documentation. It says to put squash.conf in /etc but your binary seems to be looking for it in the same directory as the squash binary. Of course now I am getting a segfault instead....

squash(118): memory violation at pc=0x0200211c, lr=0x00000001 (bad address=0x00)
pc : [<0200211c>] lr : [<00000001>]
sp : bf5ffc60 ip : bf5ffc60 fp : bf5ffd14
r10: 020072c8 r9 : 00000000 r8 : 020bb9c0
r7 : bf5ffcdc r6 : bf5ffccc r5 : bf5ffcbc r4 : 0000000f
r3 : 00000002 r2 : 00000000 r1 : 02089e22 r0 : bf5ffcbc
Flags: nzCv IRQs on FIQs on Mode USER_32 Segment user
Control: D029D17D Table: D029D17D DAC: 00000015
Function entered at [<02002070>] from [<0200280c>]
r10 = 020072C8 r9 = 00000000 r8 = 020BB9C0 r7 = 00000080
r6 = 00000001 r5 = 020BB930 r4 = 020BBBA0
Function entered at [<020025f4>] from [<0200742c>]
r10 = 020072C8 r9 = 00000000 r8 = 00000803 r7 = 00000080
r6 = 00000001 r5 = 020BB930 r4 = 020BBAB0
Function entered at [<020072c8>] from [<02031f48>]
r6 = 00000003 r5 = BFFFFDE4 r4 = BF5FFE40
Function entered at [<02031e80>] from [<0205ee0c>]
r4 = 00000000
Function entered at [<0205e2d0>] from [<02031cc4>]
r8 = BFFFFD80 r7 = 00000000 r6 = 02001C30 r5 = 00000004
r4 = 00000001
Function entered at [<02031c14>] from [<0205ee0c>]
r5 = 00000000 r4 = 00000000
Function entered at [<02033eac>] from [<00000000>]
r6 = 02033EF8 r5 = BFFFFC94 r4 = BFFFFD2C
Function entered at [<e1a04ff4>] from [<e24cb004>]
Function entered at [<0000ffc4>] from [<0000ff00>]
Unable to handle kernel paging request at virtual address 0000ffc8
memmap = D029C000, pgd = c0a9c000
*pgd = d039c801, *pmd = d039c801, *pte = 00000000, *ppte = 00000000
Internal error: Oops: 2
CPU: 0
pc : [<c00eeda4>] lr : [<c0019710>]
sp : c0acbf44 ip : c0acbf00 fp : c0acbf90
r10: 00000002 r9 : c0b9f160 r8 : 0000000c
r7 : 00000000 r6 : 0000ffc4 r5 : 0000ff01 r4 : e1a0c00d
r3 : 60000013 r2 : c01101e4 r1 : 00000001 r0 : e1a0bffd
Flags: nZCv IRQs on FIQs on Mode SVC_32 Segment user
Control: D029D17D Table: D029D17D DAC: 00000015
Process squash (pid: 118, stackpage=c0acb000)
Stack:
c0acbf20: c0019710 c00eeda4 60000
c0acbf40: ffffffff c0b9f178 c0b9e720 c0aca000 c0acbfb8 00000024 c00119c8 00000
c0acbf60: 00000024 00000002 c0acbfb8 0000000f 00000024 00000000 00000002 00000
c0acbf80: 020072c8 c0acbfb4 c0acbf94 c0011f00 c0011778 c010e97c bf5ffcbc bf5ff
c0acbfa0: bf5ffcdc 020bb9c0 00000000 c0acbfb8 c000a0a8 c0011e28 bf5ffcbc 02089
c0acbfc0: 00000000 00000002 0000000f bf5ffcbc bf5ffccc bf5ffcdc 020bb9c0 00000
c0acbfe0: 020072c8 bf5ffd14 bf5ffc60 bf5ffc60 00000001 0200211c 20000010 fffff
Backtrace:
Function entered at [<c001176c>] from [<c0011f00>]
r10 = 020072C8 r9 = 00000000 r8 = 00000002 r7 = 00000000
r6 = 00000024 r5 = 0000000F r4 = C0ACBFB8
Function entered at [<c0011e1c>] from [<c000a0a8>]
r8 = 020BB9C0 r7 = BF5FFCDC r6 = BF5FFCCC r5 = BF5FFCBC
r4 = C010E97C
Code: ebfca9d6 e2440010 (e5961004) e1a035a1 e59f20cc
Segmentation fault

now I am getting a segfault instead

Same thing if I compile my own version rather than use the precompiled. Maybe I missed something in the directions, but I think I have everything setup right.

-Mike

Hey guys, I see what you are saying about my reply. I apologize if that sounded hostile; it wasn't meant to be. I don't know what I meant exactly, but I guess I was saying that I wasn't trying to make support of all three formats a some sort of boast (in my original announcement), but more of a fact. And the fellow who replied suggested that everyone could have that same support (and so I suggested that they would have to trade that support for an "alpha" tag). But anyway, I didn't mean anything malicious, and apologies again to anyone that was offended.

Really the only thing I'm even marginally proud of about Squash, besides it more or less running, is the automatic music selection routine. More on that in a bit.

First, I want to thank everyone for responding to my paranioa with some very kind words. So, Thanks!

I think it was Tony C that suggested we discuss automatic selection algorithms in general so I'm going to post my thoughts about that in a new thread. I would like to say here, though, that Squash's method is not very complex or "anything you can pat yourself on the back for" .

And another question was which would be easier to do? Flesh out Squash (by what, six? seven-fold?), or add the unique features to the main player. Well I really think it would be easy to add to the original player. Of course, I'd probably keep using squash so long as I have no elegant way (read, rsync regularly named files) to transfer files to the unit.

Just to be careful, while that is my gripe (and I hope that's a legitimate one?), I don't want to put down everything else that the player does so well. I want to go down on the record as really liking the original player. (Especially, the recent dancing stickmen, that's just awesome ).

So anyway, thanks for the support, and sorry for my misunderstanding.

-Adam Luter (Gryn)

That is most likely a bug in my documentation. Sorry, I had changed the global configuration file location near release and forgot to update the docs. The new location is in /drive0/squash/squash.conf . The reason I changed it was so that you would have one less reason to make the root partition read-write.

I hope that clears up the segfault (which is kind of scary that it even does that, I wouldn't think so). I can't test things out right now, because I'm about 3,000 miles away from my car.

Gosh, that's a big mistake on my part in fact! I'm going to change the code right now and at least update the CVS copy of the docs.

Btw, the ~/squash_control is the default value of the control location. And if you get squash reading your new config file, it shouldn't try to read the control file there. Also, I had problems with the word_exp routine expanding ~'s on the empeg/arm environment, so I don't even bother trying. (So that is to say, on a linux pc the error message would have said '/home/gryn/.squash_control'. And that the empeg version doesn't even support expanding ~'s at all).

Thanks for the feedback.

I'll wait at least until savannah fixes there dern file area. It's a pain in the butt to use right now. But I -really- appreciate the offer.

I'd probably keep using squash so long as I have no elegant way (read, rsync regularly named files) to transfer files to the unit.

Check out mp3tofid. It may do exactly what you want.

Thanks, it may, if it made a symlink farm. But really the problem is that you have to have a database that, at the least, requires you to specially name your songs. Also mp3tofid doesn't allow you to take a filelist as input.

As it is I have all my music on one location. I want to get some of that onto my player. I have a program that will generate a random selection of those songs, and pick as many as would fit on the player. To use mp3tofid, I have to copy all these files to a temporary location. Next I run mp3tofid that makes a third copy of the files in the database format. Now I rsync that over to the player.

Another problem with this (beside the number of steps involved and the number of copies of music I have to make) is that there is no way to get information -out- of the player. That is, if the player was keeping track of what songs were played and what were skipped (the basis of Squash's selection routine), I would lose that information (assuming it was kept in the database) when I used mp3tofid.

I hope that clears up the segfault

Unfortunately it doesn't. The segfault was from after I figured out where the file needed to be. This is on a mk2 with v2final using ext3. Nothing special other than that that I can think of.

-Mike

Next I run mp3tofid that makes a third copy of the files in the database format. Now I rsync that over to the player.

it does make it from symlinks, and if i'm correct, it will also pick up symlinks in your root directory. so only one copy needed. let your random song picker make symlinks.

You can make symlinks as the last step, but it will ignore symlinks in the "input directory" (the directory I feed to mp3tofid, with my selection of songs).

I'll admit I've not used it, but I believe that you're wrong. Pim specifically created it to understand links so that the same file would only get uploaded once.

No, you are correct and I am correct. It understands links that are between items in the source tree. That is if you have a tree of music and you have created some links that point _within that tree_, then his program will detect that, maintain structure and only upload the file once.

However, if you have a master tree, and create a source tree using symlinks to the master tree, his program will not work. At least I couldn't make it. I even checked into looking to add that functionality. But all the code for the inter-tree link detection was in the way, so it wasn't easy to find where to add.

Oh, I see. I hadn't looked that hard. You could conceivably make one hard link with the rest soft links to it, but that'd be a pain to administer.

But even using hard links, soft links etc, and then automating all that, it's still not very good compared to:

Rsync (from the player to the pc) the symlink farm, which includes the database files.
Remove symlinks from the current symlink farm.
Run a selection routine, this generates a filelist.
Create new symlinks based on filelist.
Rsync (from the pc to the player) the symlink farm.

One thing that is nice, is that it's about as few steps as possible. And the only "cludgy" thing is that rsync doesn't take a filelist, that would be ideal.

The main thing is that I can transfer database changes back from the player to the pc, and then use information gathered there to pick the songs that are next.

Correct me if I'm wrong, but the writeable parts of the database are, to my knowledge, a big binary blob on that extra partition right? That's not as fun to play with as a simple text based one. Granted my current implementation isn't so fast, but it's fast enough (start up tiime -- defined as starting of music playing -- is a hair faster than the default player. But it does take about 30 seconds to finish reading the rest of the database).

Anyway, an easy to work with database is one of the reasons I wrote Squash. The second was to improve the shuffle mode (which is 95% of the time what I used). And the third was to support OGG's since that meant I could have more music on the player (I went from 3200 MP3's to 4000 OGG's). The last reason was so I would have a player at home on my pc (Squash runs on the PC (using console/ncurses), not just the empeg).

There was a brown paper bag null derefernce in the 1.0 release. Please use the 1.0.1 release if it affected you.

I put the files on savannah.gnu.org, but they don't seem to be showing up. So just use the CVS until I decide where else to host this project because savannah is reallllllllly making me upset.

Thought I would bring this thread back from the dead to see if anybody knew what happened to gryng? Schofield's post got me thinking about replacement player software and it seems like squash was the closest thing we ever had to a viable alternative, but Adam disappeared just about the time it started working

-Mike

Quote:
Thought I would bring this thread back from the dead to see if anybody knew what happened to gryng?

This software was (is) very promising and I'm thinking every day to integrate it with my I-BUS driver in order to make a more integrated product before 1.0 release. I think that the author didn't received the attention he deserved (his work is pretty brillant).