51

(20 replies, posted in Features)

52

(3 replies, posted in Features)

53

(2 replies, posted in Archives)

55

(28 replies, posted in Development)

Do I understand correctly that even PPC Macs won't be able to run Classic apps under Leopard?  That's actually a big negative for me, as I still use several Classic apps on occasion (and like to have the option), so I may not ever adopt Leopard until I get a new machine (ha ha).

Aha, Enter works nicely.  Good deal.

58

(28 replies, posted in Development)

That seems reasonable.  For those of us who might take a while to make it to Leopard, it would be great (speaking strictly selfishly here) if a lot of the little UI quirks and polishes could be in 0.08, especially stuff related to key commands.  More on that in the Features forum...

...when it's the only item in the playlist?

Neither the forward nor back buttons will do this, and moving the position slider feels kludgy and imprecise (selecting 0:00 vs. 0:01, say).

As far as I can tell, there's no good way to do this right now, and absolutely no way at all to do it via key commands.  The only real way I've found it to do it is to select "Stop" from the menu and then to hit play, which obviously isn't ideal.

It'd be great if the back button, and/or key command for "previous song", would return to the beginning of a song if it's the only one in the playlist.  Actually, it'd be great to do this for any item that's the first one in the playlist, just as a real CD player would do.

What do you think?

60

(4 replies, posted in General)

Agreed, back in my OS 8.6/9 days I always thought this was an unusually good-sounding player.  I don't know what special magic they worked with their decoder, but something about the stereo image through Audion seemed particularly vivid.  I loved their plugins, too.

61

(3 replies, posted in Features)

VSpader mentioned in another thread (one of the ones about video game music) that he didn't know of a current, open-source decoder for RAR files.  If there is one, that'd be great, because certain SNES files are encoded in a pseudo-RAR format (RSN), and it'd be awesome to be able to play them without manually decompressing them.

62

(28 replies, posted in Development)

I understand from the above why you'd want to do it, but speaking strictly for myself, I don't expect to switch to Leopard for quite a while (largely because I can't really afford it).  I think in general it's good to wait until a new version of the OS has been out for almost/at least a year before requiring it.  However, more frequent updates are a great thing -- though it'll make me sad not to get to use them!  hmm

63

(4 replies, posted in Features)

$.02 here, too.  One way this might be useful for me:  I often make mix CDs, and like to have two playlists going -- one that has everything I might possibly want to put on the CD, and another for assembling the actual mix I'm deciding upon.  It's nice having a second, individuated playlist for the latter, so that (among other things) I can keep track of total time consumption (keeping it under 80 minutes) -- something I can't do with just one PL.

64

(20 replies, posted in Features)

Maybe it could be a customizable preference?  I like the bold text, myself, though I can imagine there are fonts that would make things tricky.

66

(3 replies, posted in Squashed Bugs)

I just tried r521, and the behavior is intriguingly different.  When I do the things that would normally trigger r516 to stop, r521 keeps playing.  However, the slider then becomes essentially nonfunctional until the next song begins:  during those last five seconds of the song, I can put the slider wherever I want, and it doesn't change a thing.  I can even pause Cog, move the slider, and hit play again;  doesn't matter -- after Cog plays the audio from the last few seconds of the track, it goes to the next one.

Still, this is definitely something of an improvement -- far better for Cog to keep playing to the end of the track, which makes more intuitive sense to the average user, than to stop dead, right?  I wouldn't worry too much about getting this fixed in time for 0.07, though it'd be nice to get it fixed eventually.

Hmmm, on the other hand, I did some more testing and this now seems to happen anywhere within the last TEN seconds of a track, rather than five seconds.  Odd.

About the cue sheet issue, is this like how certain hardware CD players will manually reseek each individual track when you program them to play (say) tracks 1, 2, 3, and 5?  When you're listening to continuous material, this creates an annoying gap as it reseeks, and I'm always pleased when I use a CD player that's smart enough to know "OK, track 2 comes right after track 1, I can just let it play through without reseeking."  Can you use a simple mathematical test like that, or is it more involved?

67

(18 replies, posted in Features)

68

(3 replies, posted in Squashed Bugs)

This is a little tricky to explain, so I'll outline this as a series of steps:

1) Frequently, if I position the slider within 2-3 seconds of the end of a file, the slider will grey out and "freeze", and no music will play.  I can reproduce this bug repeatedly if I reposition the slider two or three times within the last five seconds of a file -- on the second or third repositioning, the music stops, as if Cog were paused.

1a) However, the play/pause button still displays a pause symbol, indicating that Cog believes itself to still be playing (at least from a UI point of view).

2) If I hit the pause button, it switches to the triangular play icon, while remaining as if paused...

3) ...and if I hit the button again, to resume playback, Cog immediately skips to the next track in my playlist.  If I'm at the end of the playlist, Cog just stops, with a greyed-out slider (just as if I'd played the song through to its end).

Crucial point that raises this to the status of a full-blown bug:  during Steps 1a or 2, I can reposition the slider anywhere in the track.  In other words, having gotten Cog to "jam" near the end, I can move the slider anywhere I want, and it appears that playback ought to resume from that point.

But it doesn't change a thing:  Cog won't play any audio until I go through a pause/unpause cycle (which makes Cog skip to the next track), or double-click on some track in the playlist (which makes Cog play that file from the beginning). 

Thus, it's more than a bit confusing from a UI perspective:  you're checking the end of a file and moving the slider, and suddenly Cog stops; you then move the slider back earlier in the track and try to resume playback, and Cog either skips to the next track, or stops dead.

If I had to guess, it almost seems as if something in the last few seconds of the track is triggering a Cog process that doesn't want to be interrupted -- or, at least, that doesn't want to be asked to "back up" within the same track.  Maybe there's a bug in the gapless playback code?

This may seem like a minor point, but I use Cog all the time to preview tracks I'm going to be burning to CD, and often I'll check the end of a track repeatedly to listen for artifacts of various kinds.

Oh, and:  Powerbook G4, Cog 0.06 r516, OS X 10.4.8, plenty of RAM, etc.

69

(18 replies, posted in Features)

When playing soundfiles from a data CD or DVD, the noise of the disc drive repeatedly spinning up and then back down again can get a little annoying.  The same can happen with my Firewire external hard drive, which is a little more troubling.  Sometimes this will happen about once per minute, which seems likely to put excess wear and tear on my drives.

Is there any chance of an option to tell Cog to read each soundfile into RAM in its entirety, all at once, so that the disc is only spun up once per track?  Or, at least, to take in larger chunks per disc access?

Not a high priority item, mind you, but...

71

(7 replies, posted in Development)

73

(2 replies, posted in Archives)

75

(22 replies, posted in Archives)