Re: [Pykaraoke-discuss] Visual Artifacts
On Sat, Feb 14, 2009 at 8:34 PM, Tim wrote: > > Perhaps this is a known problem, but I thought I would bring it up. > > The .cdg tracks I just ripped look normal at the beginning of a song, > but the longer you play them, the more random mis-colored artifacts > start to show up on the screen. It's like random chunks of text don't > get erased properly and start to muck up the screen over time. It > gets very distracting later in a songs. I can take a screen shot if you > aren't sure what I'm talking about. > > The funny thing is, I've seen these same problems on two separate > commercial karaoke players, one at a bar and another on a home system. > At the karaoke bar, the artifacts continued to acummulate over time on > several songs and eventually the system crashed and they had to restart > it. Fun stuff. > > Thoughts? I can chime in on this one, I think :) It's definitely a "known problem," but one known about CD+G in general, not in the player. CD+G isn't a video format -- each frame is the result of taking the previous frame and executing an instruction to change some portion of the screen. It's an old format, intentionally designed for media that is guaranteed to deteriorate with use and eventually stop working entirely. It has no concept of "lyrics" -- it's not just a pile of words and timing information. It's a stream of very primitive commands executed at regular intervals that draw pixels on the screen. In fact, CD+G consists of only a few instructions, like "set the color palette to be this set of colors," or "clear the screen by setting every pixel to this color," or "draw this 12x6 pixel image on this part of the screen." No joke, btw -- the biggest block of pixels you can draw at once is tiny. There's also some functions for scrolling, and the system is fast enough to permit rudimentary "animation" by cycling the colors in the on-screen palette. You get 75 of these actions per second to work with, and that's it. It may sound like plenty (and usually it's sufficient, though you can tell in certain discs where either they just couldn't fit everything on screen quite in time, or they didn't try very hard), but you've got two limiting factors: * It usually takes more than one "draw this block of pixels to the screen at this position" command to get a single letter (or a pair of letters if you're lucky) onto the screen because the blocks are so small. * There's no guarantee that any command has executed, and no way to tell if a previous command has executed. CD+G intentionally doesn't fail just because a command gets missed. Because the graphic data rides along with the music, you can't really go back and re-read a sector again because that bit of music has already headed out to the speakers. If you look at the spec (linked below), you'll notice that while there's parity bits to go along with the "P" and "Q" subchannels where audio CD timing and TOC data lives, there's no parity (and hence no error checking) on the rest of the subchannels, R through W, and those channels are where CD+G lives. Full details on the CD+G spec are available at http://www.jbum.com/cdg_revealed.html if you're really curious about how it all works behind the scenes. The problem you describe arises because players (even the commercial standalone ones) sometimes miss commands. This can happen because the disc is smudged or scratched, or because the player gets bumped, etc. Even if a command executes, the data coming with it can get messed up (an extra pixel turns on or off when it shouldn't). On tracks where every frame counts (think of a song like Weird Al Yankovic's "White and Nerdy" -- an insanely fast-paced parody of a rap song), and you're struggling to even get all the words on screen at all, much less in time to be read before it's time to sing them, you may not be able to afford even a single command (out of the 75 per second you get) to erase tthe whole screen and start drawing new text. Or perhaps you only have room for one, and it gets missed because the disc is smudged. Now instead of drawing on a blank slate like you're expecting, you're just scribbling new graphics on top of old (non-erased) ones. This is also what causes random pixels to stay lit up -- they weren't intended to be drawn in the first place (they were caused by a disc read error), so no command ever follows to erase the errant pixels. Every karaoke label does things differently -- Sound Choice tends to use lots of screen clears, while Chartbuster has a tendency to just erase lyrics a line at a time once they've been sung and re-use the cleared space for new lyrics. Because of that tendency, I've seen this "garbage display" problem happen more with Chartbuster discs than any other label. It gets downright awful when a read error occurs and turns a "draw a tile" command into a "change the palette!" command and all the colors on-screen get jibbered. If the tile data happens to represent an unfortunate combination of colors, you end
Re: [Pykaraoke-discuss] So, what's everyone doing with PYK?
On Jan 18, 2008 9:35 AM, Jay R. Ashworth <[EMAIL PROTECTED]> wrote: > There hasn't been a lot of traffic on this list lately, which means one > of two things: > > 1) everyone's given up, or > 2) PYK is Good Enough now. :-) PYK has always been pretty good :) The patches I submitted back (I think) in 2005 (yeesh, has it really been that long already?!?!) made it do pretty much everything I ever wanted it to do; the only thing it's missing now from a raw functionality perspective is key changing / pitch shifting, changeable at runtime with a keystroke or on the command line. Since that would involve tying in libsoundtouch and doing playback more directly (instead of just doing "load audio file, shove into playback engine"), and I haven't ever managed to get SWIG to behave, that one feature hasn't shown up :) Ok, people, which is it? Something that's slowed me down is I'm not KJ'ing anymore (professionally, anyway). When I moved to Florida, the idiot that invited me (amid promises to help get my foot in the door to host karaoke) turned out to be one of the biggest flakes I've ever known, and got herself into more personal trouble in the span of a few months than I've ever seen a person manage. Between the frustrations of dealing with that and other work turning up to keep me busy, I've never managed to actually get anything karaoke-related off the ground. I'm still very keen to build a real GUI and automation chain for the rotation management side of things, though. Myself, I'm just about to implement, having lined up a potential show > at a restaurant a friend just bought. Kelvin: did we ever look into > the "break the playback window apart from the management window" thing? > > Will? How were you dealing with that? > I've actually never used the management window thing for a show -- I just use pycdg.py directly for CDG playback (configured/controlled via command-line). My first patch to the app added a whole bunch of command-line options to help control and configure it. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] Command line options for song window
On Nov 29, 2007 7:37 PM, Mark Fiedler <[EMAIL PROTECTED]> wrote: > I follow what you are saying and that is what I am attempting to do with > the window-x parameter I am specifying. My screen 1 resolution is > 1280x1024. My screen 2 resolution is 1024x768. NVIDIA Twinview reports 1 > logical screen to the X window server with a resolution of 2304x1024. > > The parameter I gave pycdg is: pycdg --window-x=1300 song.cdg > > This should place the song window on the second screen but so far no > luck. Thanks. > What happens when you set the window to appear one pixel to the *left* of the virtual boundary, i.e. --window-x=1279? Is it *ever* possible to get the window to show up split between both virtual screens just with arguments from the command line? Is your X configured using Xinerama, or is it a fairly standard-issue NVidia config for two displays? Also, is it one adapter, or two? Can you send me your xorg.conf file so I can have a look? Thanks! - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] Command line options for song window
On Nov 28, 2007 10:50 PM, Mark Fiedler <[EMAIL PROTECTED]> wrote: > Hello, > > I ran several tests launching a song directly via pycdg. The song window > always appeared on the screen where it was launched from regardless of the > "window-x" option value. For example, if the terminal window was on > screen > 1 then the song window would appear at the right most edge of screen 1. > If > I slid the terminal window over to screen 2 and launched pycdg, the song > window appeared on screen 2. If I slid the terminal window halfway > between > screen 1 and 2, it would usually show on screen 1 unless approximately 80 > percent of the terminal window was showing on screen 2 then it would > appear > on screen 2. Pycdg did seem to recognize the other options (window-y, > width, height), just not the window-x option. Please let me know if you > have any other suggestions or need additional information. Try adding the horizontal resolution of your first display to the value you're passing in for window-x. I.e. if you've got a 1024x768 display, pass in -window-x=1024 instead of 0. X may just be addressing it all as one big display instead of two virtual ones. Last year when I ran shows I used pycdg directly and this is how I positioned the CD+G displays for my shows on the secondary port (where the audience and singer could see it), so it kept all my geeky behind-the-scenes stuff out of the public eye :) - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] pycdg segfault on amd64
On 2/1/07, Kelvin Lawson <[EMAIL PROTECTED]> wrote: Hi Daniel, > This problem was indeed happening with multiple .cdg files, though I can't > say if it applied to them all. Because pykaraoke worked with the same files > on x86 without incident, however, I doubt that corrupted/rogue data is the > issue. > > I'll send you a private e-mail re: obtaining the OGG+CDG files in > question for testing purposes. I tried these CDGs on my AMD64 and they worked fine. I guess it's system dependent whether the out of bounds array access will hit somewhere that will cause a seg fault. I suspect this is either a numeric thing or a pygame thing -- aren't there some compiled bits in those libraries for speed purposes on some systems? I recall having a 64-bit problem myself when I was first mucking with PyKaraoke myself ;) - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
[Pykaraoke-discuss] Update on Windows compilation of optimized C version of PyKaraoke
Heh. This is complicated :) Visual Studio Express Edition *does* indeed include a free C and C++ compiler. The download took awhile :P I'm piecing together what requirements are needed (and how the heck to go about actually building the whole mess), but I thought I'd mention I haven't forgotten about this little task :) -- Looking for something to read? Visit http://willfe.com/ ... now with a minty fresh flavor! - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] Quick Question
On 12/31/06, Kelvin Lawson <[EMAIL PROTECTED]> wrote: Hi Ryan, > I am wondering if someone can help me out. I want to put together a > simple python script or windows executable that can be passed a zipped > cdg+mp3 as a command line argument. Play the file (perhaps have an > option to select fullscreen or windowed playback on the command line). > I am a perl programmer and have zero experience with python but when > using the source distro and the info on the site I couldnt get past it > saying that the Numeric library couldnt be found even though I installed > it. This should be a simple script using pycdg.py and playing the file > then exiting when it is complete. I can't help much on the Windows side of things, but it's odd that you're getting this Numeric error. Have you perhaps installed Numeric for a different version of Python? (e.g. installed Numeric for Python 2.3 but are running Python 2.4?) Another point: If you use the compiled version of the CDG player you don't need Numeric, but you need to have a suitable C compiler installed. Again, I haven't done this on a Windows machine, but I'm told you'll need Visual Studio - presumably there's a free version with just the compiler. And you'll need some development libraries, at least SDL-devel. This is a bit more of a pain than just using the uncompiled CDG player which requires Numeric. Because my notebook has finally crept up on its "more than one year old" mark, it's due for a full re-install (it has some fairly exotic hardware so, as much to my surprise as to anyone else, even *Linux* is in need of a full reinstallation on this thing) so Windows will be getting attention here in about three days or so, and I'll have a chance to rebuild everything from scratch. I'll explore this and get it tested; gimme about a week total to get this documented and make sure it all works right (I'm tied up for a couple of days with some other stuff but once I get this thing back on its feet and myself unburied I'll have some time to devote to this). - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] Pykaraoke for OSX
On 11/28/06, Stief Robert <[EMAIL PROTECTED]> wrote: Hi there, i´m interested on Pykaraoke for OSX. If there´s a chance for testing a Beta i would be glad to do this for you. I usually used Winamp and a CDG plugin but now i´ve changed to an imac. I installed PyKaraoke on a mac notebook running OSX and it actually did seem to work properly except for it hiding the mouse even when the pointer *wasn't* in the display window (at least, pycdg.py, the player, worked without difficulty). I don't recall there being any special steps to make that work, at least as far as the player itself goes. Have you given it a shot and encountered an error? It's meant to be cross-platform so it *should* just work assuming you've got a working Python environment. Sorry for my bad english, i´m a native german speaker. No worries :) -- Looking for something to read? Visit http://willfe.com/ ... now with a minty fresh flavor! - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] Questions regarding MID playback features
On 8/16/06, Kelvin Lawson <[EMAIL PROTECTED]> wrote: Hi Carlos,> I checked it today, and now I got it. You are using PyGame's engine to> pay MIDI, and that makes it hard to support something like whats done on> the Windows MIDI API, which is pretty flexible. That's right, we don't have much control over MIDI playback. That said,we did have to write a fair bit of code for parsing MIDI files in orderto rip the lyrics and timing info out, so we may be able to leverage some of that.Since in the "long run" we have plans (at least, I do ;) to roll our own MP3/OGG/WAV/stream player so we can have fun things like seeking, pitch shifting, etc.,, we could always leverage some of that for some kind of lower-level poking of Timidity; at least theoretically :) > I think that the best way to solve the problem is to implement a> entirely new MIDI playback system. It's not that hard as it may seem, > because there's a lot of functionality that can be reused, but it surely> involves a lot of time, which is a luxury that I don't have right now> (or in the foreseeable future).I'm in a similar position at the moment but if anyone is interested in having a stab at it, I'd be happy to incorporate it in PyKaraoke,provide support etc.Same here! I'm rolling through four (!) paid projects right now with two more chomping at the bit to get started, yet I still want to bang away on this thing, too. I still want to add some spiffy things (like the afore-mentioned pitch-shifting and seeking, along with a time display (minutes:seconds, that kind of thing, like a standalone player), more keyboard controls, etc. BTW, I tested the C-optimized version of the player (v0.5) -- holy CRAP that thing's fast! Woot! Seriously fast :) > Anyway, thanks for your time and attention. I'll try to make some time> to play with PyKaraoke and I'll let you know of any progress that I do.Great. By the way, I forgot to give you the URL for Will's pitch-shifting FAQ:http://willfe.com/index.php/Pitch-shifting_With_PyKaraoke_and_JACK_HOWTOYay! My name up in lights ;) By the way, the pitch-shifting module I've found for Jack isn't incredibly high-quality; it sounds okay but pretty "tinny" when it's done. I think maybe chaining some kind of filter *after* pitch-shifting to smooth out the sound might help, but I haven't yet experimented with that. -- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family! - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] My additions to PyKaraoke
On 7/4/06, David Rose <[EMAIL PROTECTED]> wrote: Greetings,Over the past couple of weeks, I have exchanged a couple of emails withKelvin about some changes I wanted to make to PyKaraoke. In particular,I was interested in porting it to the GP2X ( http://gp2x.co.uk/ ), whichhad some difficult constraints.In particular, it lacks a keyboard and mouse, or any kind of windowingsystem, so I needed a new frontend. Towards this purpose, I wrotepykaraoke_mini.py, which serves as a minimal frontend for environments lacking a keyboard/mouse. It presents the entire song list as a singlescrolling list, which you can rapidly shift through by holding down thearrow keys (or, in the case of the GP2X, the joystick).I also had some performance issues with the CDG decoder. I see from looking at the code that considerable effort has already been put intooptimizing pycdg.py, but it still wasn't quite fast enough for my little200Mhz CPU. I solved this problem by porting the CDG decoding part of pycdg.py down to C. Specifically, I moved the Python CDG implementationinto pycdgAux.py, and designed it with a narrow API to pycdg.py (whichstill maintains the song timings and the screen blitting and stuff); and then I write _pycdgAux.c, which exactly duplicates the behavior ofpycdgAux.py. In fact, you can switch back to the Python implementationby removing the underscore from the import statement in pycdg.py. Ooooh, does this mean there's now a C-based CDG renderer in PyKaraoke? [drool] This makes higher framerates possible at higher resolutions (maybe :). For rendering MIDI files, I had to introduce word-wrap to get the textto fit on the little 320x240 screen. I also reworked the renderingengine in pykar.py quite a bit.Finally, I ended up reworking the whole system quite a bit, to solve some issues I had with use use of threads (I finally removed threadsaltogether) and to solve some issues with maintaining state across asingle session of multiple song performances; and also to unify common code into shared base classes where appropriate.I'm happy to report it all appears to work. I took my GP2X with a groupof friends camping last weekend, and we were able to enjoy a round ofkaraoke around the campfire. Also, I've put some effort into ensuring that everything still works well in the Linux and Windows ports as well.But, I can't test everything. I haven't been able to test the OSX port,since I don't have a Mac. I'm not sure the CDG scrolling works, since I don't have a CDG disk that scrolls. And I haven't really been able totest MPG's at all.This is damned impressive anyway though :) See below. Would anyone like to help me test? I've just sent my changes to Kelvinfor review and eventual incorporation into the codebase, but if anyoneon this list feels like jumping the gun, you can download it at: http://www.ddrose.com/~drose/pykaraoke-drose-2.tgzYou can unpack it and install it in the usual way. Since there's now aC component that depends on SDL, there might be just a bit more effort involved in installing it. On Linux, you need to have the SDL headersinstalled into /usr/include/SDL (which is the standard place for them). On Windows, you will need to unpack the SDL source distribution somewhere, then tell python where to find it. I have unpacked it rightwithin the pykaraoke source directory, so I can compile and install onWindow using:python setup.py install --include-dirs=SDL-1.2.11/include --library_dirs=SDL-1.2.11/libFor the benefit of those Windows users who don't have a compiler handy,we can still distribute a Windows installer. I just built one at: http://www.ddrose.com/~drose/pykaraoke-drose-2.exeLet me know what you think!DavidI'll test this thing out over the next couple of days. Thanks for sending this along! -- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family! Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] freedb.org
On 7/3/06, Drew <[EMAIL PROTECTED]> wrote: On Saturday I was playing around writing programs in C which talk to thefreedb server and retrieve track listings. This is all with a view toadding track lookups to my ripper (which is a fairly crucial feature). While I was on the freedb.org website, looking for the how-to, I saw apost from the tow guys who apparently run it saying that they wereleaving.I just got my program working and was about to start transferring the code into my ripper... then...Today I see that the main page has a message which starts:"freedb is not able to operate without Joerg and Ari. There are other -hopefully free - projects that will take over" At the moment it seems to still be working but I'm not sure howlong that will last.Any ideas about alternatives?I was under the impression that freedb2.org will be "taking over" the role for freedb.org in a bit. There's not much there for now though except a lookup engine. No idea how the API is going to look... But yeah, that in-fighting and immaturity going on there is annoying :(-- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family! Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] RW vs RW_RAW (was New ripper)
On 6/29/06, Drew <[EMAIL PROTECTED]> wrote: On Thu, 2006-06-29 at 20:37 +0100, Drew wrote:> I've had an idea, I'll write a program to inject some recognisable> subcode into a RW_RAW image. Then I'll burn the image with the injected> subcode, read it back with cdrdao in RW mode and look for the sub code > in the image.>> Seems like along winded way round, but I suppose it's not a very complex> programming exercise.>> I'll post if it works :)I've written the program, injected the subcode but now I can't find a way to burn the imageWhat do people use to burn a toc/bin with subcode?I use cdrdao with this command:sudo cdrdao write -device /dev/hdc -speed 4 disc.tocInside the TOC file, instead of: // Track 1TRACK AUDIOuse:// Track 1TRACK AUDIO RWwhich tells it to write subchannel data.Here's track 1 from a complete example, as written by the cdg2bin.py tool I added to cdgtools: // Track 1TRACK AUDIO RWNO COPYNO PRE_EMPHASISTWO_CHANNEL_AUDIODATAFILE "disc.bin" 06:17:01 // length in bytes: 69219648This produces discs that standalone CDG players grok just fine. The -speed 4 bit is to ensure they play without glitches. Damned old players are picky. -- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family! Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] RW vs RW_RAW (was New ripper)
On 6/29/06, Drew <[EMAIL PROTECTED]> wrote: I've had an idea, I'll write a program to inject some recognisablesubcode into a RW_RAW image. Then I'll burn the image with the injectedsubcode, read it back with cdrdao in RW mode and look for the sub codein the image. Seems like along winded way round, but I suppose it's not a very complexprogramming exercise.I'll post if it works :)Heh. Just use a CD-RW disc; then you don't even waste a piece of media :) -- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family! Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] The Other End: ProShow; a playback controller for commercial hosting
On 6/25/06, Jay R. Ashworth <[EMAIL PROTECTED]> wrote: On Sun, Jun 25, 2006 at 02:13:48PM -0400, William Ferrell wrote:>On 6/25/06, Jay R. Ashworth <[1]jra@baylink.com> wrote:>> On Sun, Jun 25, 2006 at 01:36:00PM -0400, William Ferrell wrote: > >I've relocated to Florida (Palm Bay), and am trying to set> >up shop here as a KJ.> Well, no shit. Welcome to sunny (where, by sunny, right now I mean> 'rainy') Florida. >>Indeed. It's quite a bit nicer than Colorado's weather though.I'll bet.Heh. Yeah. You joke until you realize that last year it SNOWED IN JUNE there. That sucked, and filled me with much annoyance. Colorado natives can NOT drive correctly in snow. They all just buy four-wheel drives to compensate. At least the wrecks are entertaining as long as you're not involved in them :P > >but software projects are paying the bills right now. I've got> Was that what brought you here?>>No, not really. A woman did. You'd think I'd have learned from the first >time I moved from one state to another to live with somebody -- maybe I'll>learn from this one.So I found out further down, and forgot to go back and edit this. Niceto have a portable skill, though, isn't it? It is, yes. I love freelance software development. Because I'm single (dammit) and have no local "ties" really I can just up and "take a vacation" to some other exotic spot (though for now, Florida is plenty "exotic" compared to my previous port of call) and keep on working; clients rarely (if ever) need to actually meet face-to-face. >Same here. I've got a Python module built that can automatically>handle song rotations ( i.e. you hand it names, songs, etc., and>it timestamps each submission (and new singer), counts total>performances by each singer per night, and performs weighted,>balanced rotation management to keep the "average wait time per >singer" down.How does that play in Peoria? Most of the KJs in my market use strictrotation, and most of the circuit singers don't well tolerate anyonewho doesn't. Including me. :-) I've been to many karaoke shows here in Palm Bay/Melbourne now, and I am consistently annoyed with how rotations run, because nobody runs them like I do. :)Nobody seems to run a rotation the same way either, and the net result is people end up waiting too long. The guy who runs most of the shows I attend now does something really funky -- instead of smoothly blending new and old singers together into rotations, he does it in batches. One old singer, three new ones, one old one, four new ones, etc. That has the effect of putting people off and making people wait longer than necessary. The management system I wrote was initially just strict rotation (FIFO), but that doesn't fly. The new one was designed with these principles and goals in mind:1) A singer who arrives early (or at least on time) at show start and stays until the show closes should get to sing more songs (and with as "even" a wait between songs as possible) than someone who turns up later. 2) A singer who shows up an hour before the show closes should have at least a *chance* to sing one song if at all possible.3) Apart from respecting 1 & 2, singers should sing on a first-come-first-served basis, mixing new singers with old once the first rotation is finished. The end result of all this juggling is that a person who shows up right at 9:00pm at show start will still get to sing three songs if I have forty singers in a night, while someone who shows up at midnight (show closing at 1:00am) will sneak in and get one song. Everybody else waits a uniformly average amount of time ( i.e. everybody waits about the same amount of time, give or take a few minutes, between their songs). That wait increases as people get added, but it's uniform; there's no "special treatment".It always went over very well in Colorado, mostly because the computer *displays* the whole process (you see your name appear in a different color if you're a new singer, and you see the colors staggered) between every song and people can see where they are on the rotation. When someone sees the list grow and change, they understand they're not the only singers and don't bitch about wait time. When they see that when they're new, they bump somebody, they don't get upset when a new singer bumps them later. When I ran this rotation method without showing it on screen anywhere, people constantly asked when their turn was, how long the wait was, etc. Since I started showing the whole thing in a grid, those questions all but stopped. It may actually just be showing people how it's working that makes it effective, not the method itself, but it d
Re: [Pykaraoke-discuss] New ripper
On 6/25/06, Jay R. Ashworth <[EMAIL PROTECTED]> wrote: On Sun, Jun 25, 2006 at 06:46:05PM +0100, Drew wrote:> > Well, having finally gotten SuSE 10.0 onto my laptop and the 100GB> > drive (which freed up the 80GB to go in the external chassis), I'm> > about to start ripping my 400 disc library -- which includes a lot of > > brands, though only a couple Sound Choice and Music Maestro discs -- so> > I guess I can A/B compare them, and see what I get. Even a 10% speedup> > is worth it on 400 discs. :-)> > I'm pretty sure you'll see a speed increase. As far as ripping all 400> disks my code is missing some important features that cdgrip.py has. The> main ones are the track name lookups and the ability to use lame instead > of oggenc.Ah. Well, ogg is fine with me, as long as the player will track it.FreeDB is a bit more important -- you'd be surprised how many karaokeCDGs are actually in there. I feel the need to chime in here and say Ogg Vorbis is *very* important here, especially when ripping a bigger collection. There's logistic, performance, and legal reasons why Ogg Vorbis is the appropriate format for compressed audio at a karaoke show. Some of this is anecdotal for me, since I've done it myself and have seen these benefits, but I haven't actually done a "laboratory-style" suite of tests to prove these things. Though some of it is pretty damned easy to demonstrate anyway. 1) Same sound quality (or better) -- Ogg Vorbis does a great job compressing music; of course this is subjective but Oggs always sound either indistiguishable from the same music compressed by MP3 or perceptively better. 2) Better compression ratios -- Oggs end up smaller than MP3s for the "equivalent" compression settings; i.e. if it sounds the same as an MP3, it'll be smaller as an Ogg, and if an Ogg the same size as an equivalent MP3, it will have fewer artifacts and generally sound better. 3) Faster compression/decompression -- On my 64-bit (AMD Athlon 64) notebook, Ogg encoding can sometimes run almost twice as fast as equivalent MP3 encoding. It's such a huge performance improvement that when I put a pile of Oggs together to re-convert back to MP3 to burn to a CD my truck's MP3-capable (but not Ogg-capable, dammit) player can grok, I'm disappointed that it takes more time to actually convert the files than it does to write the physical disc. 4) Royalty/patent free -- I know it's mostly an "academic" issue since MP3's patent holders haven't apparently been complete bastards about it, I don't have to worry at all that some lawyer or cop will walk in during one of my shows and shut me down for not paying a licensing fee to use a patented audio decoder. Same with releasing software that uses it; my understanding is that the MP3 folks *do* raise an eyebrow occasionally on players if those players generate revenue for their builders/authors. I haven't made empirical comparisons for the rest of this but I suspect Ogg's tags can hold more data (they can be longer than ID3 tags), I know players seem better-behaved (xmms is definitely faster/more cooperative playing Oggs than it is playing MP3s, at least on both my systems), etc. And let me tell you this: on a song collection exceeding 40,000 songs, pushing 150GB, converting from MP3 (I kept the originals, don't panic) to Ogg Vorbis dropped the collection down to 110GB and sounds just as good. > > Has anyone looked into cdparanoia?>> I couldn't find an option for ripping with subcode but I didn't look > that closely.Amusingly, googling for cdparanoia subcode turns up...me and Will, talking about whether it will do it or not. :-)That's hilarious. I'd really love to find a way to either play CDG straight from a CD or be able to rip just one track (during a show, it'll be a pain in the ass if someone brings their own disc to play but doesn't hand it to me until it's their turn to sing ... "yeah, it'll be about ten minutes before you can sing this because my computer has to read the whole disc first") -- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family! Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] The Other End: ProShow; a playback controller for commercial hosting
On 6/25/06, Jay R. Ashworth <[EMAIL PROTECTED]> wrote: On Sun, Jun 25, 2006 at 01:36:00PM -0400, William Ferrell wrote:>I've relocated to Florida (Palm Bay), and am trying to set>up shop here as a KJ.Well, no shit. Welcome to sunny (where, by sunny, right now I mean 'rainy') Florida.Indeed. It's quite a bit nicer than Colorado's weather though. >but software projects are paying the bills right now. I've gotWas that what brought you here?No, not really. A woman did. You'd think I'd have learned from the first time I moved from one state to another to live with somebody -- maybe I'll learn from this one. > There's a lot left to automate, as for now I run things by>hand as far as firing off new CDG songs, videos, etc. Yep.And it's that "by hand" stuff I want to package up and automate.Same here. I've got a Python module built that can automatically handle song rotations (i.e. you hand it names, songs, etc., and it timestamps each submission (and new singer), counts total performances by each singer per night, and performs weighted, balanced rotation management to keep the "average wait time per singer" down. Ironically I'm not using that right now at all since I put the new display software together. I'm curious about the new hardware you're talking about (with touch-screens not requiring a pen, etc.); we'd previously talked about older/cheaper hardware but I'd like to see these new targets. > And where's your blog again?>>[2]http://willfe.com/ I haven't written much in it lately, mostly>because the biggest reason I moved here in the first place turned>out to be one hell of a lie (it involved a woman, go figure) and >there just hasn't been much motivation to actually write.Wow. That blew up? Damn; sorry, guy.Well, the experience has taught me (the hard way) that she'd not have been a good mate anyway. I could probably have handled just about any of her "quirks" and the many poor choices she's made, regarding me, herself, and others in her life, but the continuing lying (yes, present tense) that she insists on pulling has proven itself to just be part of her nature, and that is something I can't deal with. She acts apologetic and offers an olive branch (classic "let's just be friends") when she sees what this has done to me, but to this day she maintains an "image" of the world that she'd like me to see, and I know much of it to be false. For all her intellect, she honestly doesn't seem to understand that she lives in a world where other people she's mucked with aren't afraid to talk to me about things she's done or said. -- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family! Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] The Other End: ProShow; a playback controller for commercial hosting
On 6/25/06, Jay R. Ashworth <[EMAIL PROTECTED]> wrote: Ok, I'll admit; that's *almost* all I've got so far. :-)Not quite: I have a paper sketch of a screen layout.I need to figure out Glade, which I gather is the prototypingenvironment of choice for complicated user interfaces. As I've discussed before, though, primarily with Will, who's done muchof this already, though not all in one place, my goal is to create aone-screen, full-screen interface that handles multiple playlists (karaoke, background, sound-effects, etc), possibly driving multipleoutputs (my Terratec Phase 26USB will generate 3 stereo pairs to feedmy mixer), and potentially interface with wireless songbook tablets (mycurrent target is the Fujitsu Point 510 or 1600; the touchscreens of which are 800x600, color, and don't require a pen).How *have* things been going with your lashup these days?I've relocated to Florida (Palm Bay), and am trying to set up shop here as a KJ. I'm making some progress in that area (feels like more "sideways" than "forward" movement though), but software projects are paying the bills right now. I've got a lot of things as far as a hosting platform working on a "by hand" basis; I use JACK for low-latency audio production, mplayer for video/multimedia playback, xmms for filler music playlist management and visualizations (projectM), and Firefox to display rotation information on the screen. PyKaraoke is used for actual CDG playback; I don't use 100% of the screen for it, but instead leave a bar at the top and bottom now (top shows name of singer and song title, bottom shows a smooth line-by-line scroller that shows the next few singers and promotional texts). The HTML in use now auto-generates the bulk of the screen via _javascript_; I just fill in names, song titles, and group assignments, and mark who's up, and it auto-generates the rest, including the grid, "who's next," etc. There's a lot left to automate, as for now I run things by hand as far as firing off new CDG songs, videos, etc. And where's your blog again?http://willfe.com/I haven't written much in it lately, mostly because the biggest reason I moved here in the first place turned out to be one hell of a lie (it involved a woman, go figure) and there just hasn't been much motivation to actually write. -- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family! Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] New ripper
On 6/6/06, Drew <[EMAIL PROTECTED]> wrote: Hi all,I posted a few months ago with a plan about building a karaoke systemusing pykaraoke. One thing I noticed was that cdgrip was a little slowto rip and I wondered if I could make any improvements. What kind of slowness do you experience with it? I've actually been pleased with its performance; it essentially just deinterleaves the CD+G and audio data, writes them to separate files, does a FreeDB lookup, and invokes lame or oggenc to encode the audio. I wrote some code in C and got to the stage of having it ripping to oggusing oggenc as the encoder. Excellent :) It's always a good feeling when you get that first successful run from a new tool :) There are some differences between my code and and cdgrip (apart fromthe language of choice)* It is a little bit faster (maybe 20%) probably mostly as a result ofbeing compiled.Which parts are faster? Have you done any profiling to see which parts are (apparently much) faster in the C version? It'd be interesting to know where the bottlenecks are in cdgrip. * It works on the bin file by analysing the q subcahnnel so never needsto look at the TOC file Oooh, now this is cool. Has it been accurate so far in getting tracks split correctly?If this works well, it'd be useful to me since I'm looking for a way to rip/encode just *one* track on a disc, and not the whole disc (Linux is still missing a play-CDG-tracks-straight-from-a-real-CDG-disc program as far as I know, and this would be a close substitute until such a tool exists (or I shut up and write one :P)) It occurs to me if I run an all-digital karaoke show with this suite and the stuff I've written up to now, I'm boned if someone walks up when I call their name, hands me a disc, and says "track 12." As it stands right now I'd have to rip the whole CD and convert it all (I could "neuter" cdgrip and have it skip the encode step, just writing to WAV, which pykaraoke will play, but we're still talking about at least six minutes to rip and split the data). * Because of the above it will probably work with cue/bin files althoughI don't have a way to test this at the moment. Have a quick look at bchunk if you get a chance; it works with the ISO and cue/bin formats and this will probably tell you whether your tool will easily adapt to the formats. * It combines the ripping and deinterleaving and also performs a CRC onthe q code block in to one step (this might give some speed benifits)Interesting; I suspect this does speed things up a bit. What's wrong with it?* It's in CThis is not a fault, but a choice :) * It's unfinished and doesn't do CDDB lookups yet* I can't make it work with LAME and I've not idea why :) What happens when you try?Some other notes.While I was writing it (I call it dcdgrip) I tried to write a NoDeinterleave option like cdgrip has. It didn't work properly, and Ithink the same option in cdgrip might also be broken (mostly because Ijust copied the code and translated it into C).I think that maybe the deiterleaved data returned by cdrdao doesn't look the way the code expects. Or the drives I've made work with the rwoption are returning something odd. It's hard to track down the sourceof these errors.Yeah, drives are very random and finicky about this part of things. Figuring out whether you've been handed raw or cooked subchannel data is a pain in the [EMAIL PROTECTED] :) Anyway...Is anyone interested in the code?Sure :) Toss it up to the list if you'd like or send it privately; I wouldn't mind seeing it. I got to the current stage over a month ago but have been too busy towork on it since. I've got a bit more free time now. I'll post it or upload somewhere or whatever if anyone is interested.Also I'd say it was GPL but I took some public domain code for a CRCalgorithm and I'm not sure how that works with the GLP (in any case the CRC stuff could be rewritten if needed)Public domain sounds "GPL-compatible" to me, but IANRMS so take that advice with a grain of salt :)-- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family! ___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] Changing font of pykaraoke
On 4/22/06, Jay R. Ashworth <[EMAIL PROTECTED]> wrote: > On Sat, Apr 22, 2006 at 03:34:36PM -0600, William Ferrell wrote: > > On 4/17/06, Jay R. Ashworth <[EMAIL PROTECTED]> wrote: > > > Yeah... as I say, I think that's why they didn't allow people to > > > actually put it on as text: that would be *much* easier to extract. > > > > > > But if you run your X server at 640x480, full screen, things ought to > > > work out just fine -- and quite a bit faster. > > > > Actually I think there's a less nefarious reason behind this (occam's > > razor, and all that) -- producing a graphics chip with far less > > computing horsepower and fewer features than an 8-bit NES is *way* > > cheaper than one that would have to do the graphics stuff, handle > > timing, *and* draw actual letters. > > You think? Hmm... Never really considered it. > > I think it might have been a push; when did CD+G hit? Mid 90's was its big hurrah if I remember, though it was probably in development much longer. Early 90's would be my guess. The cost of hardware would have most definitely been a major factor in developing the standard. I wrote a proportional-spaced font blitter for an LCD once. *shudder* I'd honestly have rather stayed playing with just rendering fonts on my own software and blitting full-screen bitmaps to the sucker. > > You'd have to offer up different fonts, styles, etc., and send strings > > and timing info along to the chip instead of simple graphic > > instructions. The way it's done now, you can use whatever visual style > > you like as long as it can fit in the low-bandwidth constraints of the > > CD+G format. > > Yeah, but is that effect, or cause? :-) We'll never know for sure since none of us (that I know of :) were in the meetings :) It does make sense either direction though. Consider that even if they'd placed font-writing functionality in the spec, it'd have been in *addition* to, not in lieu of, what's already there -- scrolling, blitting color blocks, setting the palette, etc. Letter drawing was definitely feasible -- the NES was doing it years earlier with relatively little effort. You've got to figure they wanted to keep the thing as flexible as possible (even if font-writing were available, each label would want its own distinct style and feel -- that's definitely been achieved; DK, Sound Choice, StarDisc, and Top Hits Monthly all have very identifiable visual styles that I can pick out in an instant now that I've been KJ'ing for awhile). Leaving the font-drawing up to the graphic designers meant the spec could ship faster on cheaper hardware, and left the "fancy" stuff to the CD+G users (authors). It's much easier to generate a pretty graphics-only CD+G file on a PC than it is on the lil' player; this decision (if it went the way I think it did) shifted the work of getting the font shapes and positioning right from the player to the authoring platform. -- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family! --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642 ___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] Changing font of pykaraoke
On 4/17/06, Jay R. Ashworth <[EMAIL PROTECTED]> wrote: > On Mon, Apr 17, 2006 at 05:47:09PM +0200, Cyrill Helg wrote: > > Am Montag 17 April 2006 15:52 schrieb Jay R. Ashworth: > > > On Mon, Apr 17, 2006 at 11:35:48AM +0200, Cyrill Helg wrote: > > > > First of all thanks for the cool application. My issue: I would like > > > > to change the font size of the text displayed, because I'd like that > > > > everyone can read it from my computer... > > > > > > > > Is this possible? > > > > > > If what you mean is the user interface, yeah, probably. But I suspect > > > you mean the actual displayed song lyrics, and that answer is "no, the > > > text displayed on the screen is an actual *picture*; the program > > > doesn't generate it". > > > > > > I've always assumed it was done this way because record labels were > > > afraid people would extract the text and do nefarious things with it. > > > > Always the same stupid idiots... I'll write a script to extract the > > texts with OCR and the publish it on the net :-D Just kidding, thanks > > for your answer, I hope this works, otherwise I could change the > > resolution of my X-server as a workaround. > > Yeah... as I say, I think that's why they didn't allow people to > actually put it on as text: that would be *much* easier to extract. > > But if you run your X server at 640x480, full screen, things ought to > work out just fine -- and quite a bit faster. Actually I think there's a less nefarious reason behind this (occam's razor, and all that) -- producing a graphics chip with far less computing horsepower and fewer features than an 8-bit NES is *way* cheaper than one that would have to do the graphics stuff, handle timing, *and* draw actual letters. You'd have to offer up different fonts, styles, etc., and send strings and timing info along to the chip instead of simple graphic instructions. The way it's done now, you can use whatever visual style you like as long as it can fit in the low-bandwidth constraints of the CD+G format. -- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family! --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642 ___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
[Pykaraoke-discuss] Pitch-shifting HOWTO updated
I've updated my HOWTO to include more configuration details for MPlayer, version numbers for packages used, and more automation details (including a basic script). Have another look if you're curious about such things :) http://willfe.com.nyud.net:8080/index.php/Pitch-shifting_With_PyKaraoke_and_JACK_HOWTO Thanks, all! -- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family! --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] [HOWTO] Implementing pitch-shifting and crossfading (for filler music/other sources) for PyKaraoke on Linux with JACK
On 4/8/06, Jay R. Ashworth <[EMAIL PROTECTED]> wrote: > [ lost address; pressed for time; please reply back onto list? ] Not a problem :) I've done that before ;) > On Fri, Apr 07, 2006 at 08:06:06PM -0600, William Ferrell wrote: > > On 4/7/06, Jay R. Ashworth <[EMAIL PROTECTED]> wrote: > > > On Fri, Apr 07, 2006 at 12:29:58PM -0600, William Ferrell wrote: > > > > This HOWTO attempts to document how the whole thing fits together, how > > > > to implement it on your own system, and how to use it in production at > > > > a karaoke (or really any DJ'ed) show. > > > > > > This is really spiffy. I'm not sure how easily I'm going to be able to > > > integrate it with the control-top I want to construct (which I've > > > finally, at least, sketched out, and am trying to learn Glade to mock > > > up), but... > > > > Yeah, I'm still trying to get some of the interface elements down > > better. It's usable right now thanks to Enlightenment but it could > > definitely be better. > > I will Try Really Hard to get a mock up of my design into a format you > can look at, this week. Excellent, thank you! > > > Specifically, it can talk to my Phase 26 USB box, with 3 stereo outputs > > > (I'm very much a "real mixing board" kind of guy). > > > > Ooooh, spiffy :) I likey :) > > Terratec, specifically. Has a simultaneous input as well, with a mic > pre. I need to dig around and find one of these; this takes me a step closer to an all-digital show. In fact the only missing piece apart from digital mixing is a lack of straight-from-CD CD+G player, which is something I'm interested in doing anyway, and I think Python can do it. Any hints or thoughts, Kelvin? > > The site claims it can be controlled via the ALSA sequencer, though, > > so it looks like it's possible. > > Ok. In my case, again, it's because I want the control surface to be > all-encompassing; I'm planning on a 17" touchscreen (with a > micro-keyboard for entering search terms, optionally -- you could do it > with a popup keyboard). [droolification] > > > And, BTW; kudos on the site; blogging with MW isn't easy. > > > > Thanks, and you're right, it's a pain in the ass. I had to modify code > > to make that work. I'm tempted to switch it to Plone instead. > > I was looking at using Category tags, and a custom extension based on > DPL 2, to do it myself. Cause having each entry be a first-class > article is useful as hell. http://willfe.com.nyud.net:8080/index.php/My_MediaWiki_Hacks Go read that -- it describes what I did to implement exactly what you describe. And I hacked DPL2 ;) so that's exactly what you want. I'm using Categories to tag things, too, and all entries are first-class articles. Hehehe. The link is Coral Cache-ified by the way because I'm expecting heavy traffic in a few days; a not-so-friendly company is threatening to sue me because I posted my experience with them on my site, and negotiations broke down recently. I went public with the details, and Tom Martino (the "Troubleshooter") is going to have me on his radio program Monday to hash this stuff out. Heh. This should get interesting fast :) -- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family! --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] [HOWTO] Implementing pitch-shifting and crossfading (for filler music/other sources) for PyKaraoke on Linux with JACK
On 4/7/06, Jay R. Ashworth <[EMAIL PROTECTED]> wrote: > On Fri, Apr 07, 2006 at 12:29:58PM -0600, William Ferrell wrote: > > This HOWTO attempts to document how the whole thing fits together, how > > to implement it on your own system, and how to use it in production at > > a karaoke (or really any DJ'ed) show. > > This is really spiffy. I'm not sure how easily I'm going to be able to > integrate it with the control-top I want to construct (which I've > finally, at least, sketched out, and am trying to learn Glade to mock > up), but... Yeah, I'm still trying to get some of the interface elements down better. It's usable right now thanks to Enlightenment but it could definitely be better. > > The JACK Audio Connection Kit is a real-time virtual mixing board for > > Linux (and possibly other platforms; I haven't yet investigated this) > > I understand JACK has been ported successfully to OS/X now, which > probably isn't too surprising. Yeah, that's spiffy. I haven't got a Mac to test it with though :( > > that uses a low-latency server and protocol to connect sound > > applications and devices to each other. It can control all sorts of > > real hardware (sound cards, MIDI controllers, etc.) and can accept > > inputs from just about anything (media players, MIDI controllers, > > etc.) for both audio and control. > > Specifically, it can talk to my Phase 26 USB box, with 3 stereo outputs > (I'm very much a "real mixing board" kind of guy). Ooooh, spiffy :) I likey :) > > JACK includes a useful tool, qjackctl, that will be used in this HOWTO > > to configure JACK and to automate patching our different tools > > together. > > You do *not* want to try to play with JACK without qj; take my word on > this. Oh I learned that the hard way :) > > This HOWTO uses JACK Rack for two things: first, it is used to perform > > the actual pitch-shifting work when needed (audio from PyKaraoke is > > passed to JACK Rack instead of straight ot the sound card). Second, it > > performs crossfading work; I use different audio sources > > (specifically, XMMS and MPlayer) during my shows, and smoothly > > transitioning from them to CD+G music and back is important. JACK Rack > > is, in this configuration, the only piece of software on the chain > > that is connected to the sound card. All audio playback runs through > > JACK Rack whether it is doing anything to the sound or not. > > Can JR, or the modules it encases, be controlled by DBus (or any other > message passing facility)? I don't know yet; I need to test some more things. I sure hope it can -- I'd love to be able to control the crossfader with a real slider, for example. The site claims it can be controlled via the ALSA sequencer, though, so it looks like it's possible. > > It supports MP3, Ogg Vorbis, WAV, FLAC, and all sorts of other audio > > formats. It can play video (via MPlayer, actually), but we want manual > > control over that kind of thing so we'll only be using XMMS for audio. > > Mplayer is sort of ungainly for playing audio directly, isn't it? Absolutely; I only play videos with it. It overlays the normal display while it plays. > > MPlayer is a multimedia player for Linux. It supports audio and video > > playback, tons of media formats, lots of output devices and types, and > > has more features than I can adequately count here. > > Here's a curious idea: I wonder how hard it would be to recast Kelvin's > rendering code as an Mplayer codec? Did we already talk about this? Hmmm... that'd be interesting; Mplayer is good at dealing with scaling. We could just feed it the unscaled bitmap and let it handle scaling. > > For our purposes, we'll simply be chaining it to JACK as an audio > > source (letting it do its own thing for video, if needed) so we can > > crossfade between it and the filler music XMMS provides. > > How *are* you deconflicting video output sources, anyway? Mplayer uses SDL for video *and* audio on this machine since OpenGL and XV support broke a few months ago (the bastards :). I don't run Mplayer and PyKaraoke simultaneously, though they can do so without breaking. The Patchbay thing figures it out properly. > Note: SuSE, in particular, tends to have an out of date JACK; I > wouldn't be surprised to find that other distros do as well -- Will? > Could you document the version numbers of all your components? Absolutely, I'll update the writeup tonight or tomorrow with numbers. > This is *nice* detail, Will. Thanks :) > > 2.2. Setting Up the Sound Processor (JACK Rack) > > > > Start up JACK Rack (the command
[Pykaraoke-discuss] [HOWTO] Implementing pitch-shifting and crossfading (for filler music/other sources) for PyKaraoke on Linux with JACK
PyKaraoke doesn't currently support pitch-shifting natively during song playback, and this is about the only missing feature that prevents PyKaraoke from being a complete digital replacement for the traditional analog CD+G player. This is the case because PyKaraoke relies on Pygame's MP3/Ogg/WAV playback engine, which does not (currently) provide any means of applying effects filters to the sound before it hits the sound device. It would be possible to replace this with our own threaded MP3/Ogg/WAV player, and use libsoundtouch to perform pitch-shifting (it is a very high quality, faster-than-realtime pitch shifter and time compressor/expander), but that's a significant undertaking. There are no Python bindings for libsoundtouch, so using it would mean mucking with SWIG, which has always given me fits. On Linux at least, there is an alternative solution that ultimately provides more flexibility anyway in building a sound layer that permits all sorts of cool sound effect possibilities. This HOWTO attempts to document how the whole thing fits together, how to implement it on your own system, and how to use it in production at a karaoke (or really any DJ'ed) show. 1. The Architecture. The system we'll be building uses JACK to connect different sound applications together and to the machine's sound card. PyKaraoke will provide the CD+G audio source that we'll be applying pitch-shifting effects to. XMMS will provide filler audio in this example, simply because it has a JACK output driver and is easy to work with. It also has a high-quality crossfader plugin that produces outstanding audio results. JACK Rack, with Tom's Audio Processing LADSPA plugins providing pitch-shifting. As an added bonus, I'll demonstrate how to get MPlayer into the mix as well, to provide multimedia clips at shows where a television or projector is available. 1.1 JACK http://jackit.sourceforge.net/ The JACK Audio Connection Kit is a real-time virtual mixing board for Linux (and possibly other platforms; I haven't yet investigated this) that uses a low-latency server and protocol to connect sound applications and devices to each other. It can control all sorts of real hardware (sound cards, MIDI controllers, etc.) and can accept inputs from just about anything (media players, MIDI controllers, etc.) for both audio and control. It can make use of a stock Linux kernel, or one that has been configured with preempting and real-time features to ensure no pops or gaps in audio playback even when many different tools are in active use on the chain. JACK includes a useful tool, qjackctl, that will be used in this HOWTO to configure JACK and to automate patching our different tools together. 1.2 JACK Rack http://jack-rack.sourceforge.net/ JACK Rack is a sound processor designed for use with JACK exclusively; it presents a configurable number of "default" channels to JACK and can load effects modules (like "echo," "pitch shift," "reverb," etc.) in any order. Sound flows through the modules top-to-bottom as they're shown in the interface. Modules can be enabled or disabled (when disabled, they do nothing to the sound; it simply flows through them to the next module), and moved up and down in the stack. This HOWTO uses JACK Rack for two things: first, it is used to perform the actual pitch-shifting work when needed (audio from PyKaraoke is passed to JACK Rack instead of straight ot the sound card). Second, it performs crossfading work; I use different audio sources (specifically, XMMS and MPlayer) during my shows, and smoothly transitioning from them to CD+G music and back is important. JACK Rack is, in this configuration, the only piece of software on the chain that is connected to the sound card. All audio playback runs through JACK Rack whether it is doing anything to the sound or not. 1.3 XMMS http://www.xmms.org/ XMMS is a multimedia player for Linux. It is an older piece of software (not actively maintained anymore; its developers are focusing on a new 2.0 release), but assuming it'll start up and run on your system, it's very reliable and useful for this purpose. It supports MP3, Ogg Vorbis, WAV, FLAC, and all sorts of other audio formats. It can play video (via MPlayer, actually), but we want manual control over that kind of thing so we'll only be using XMMS for audio. XMMS' plugin system means we can get automated crossfading between songs XMMS plays *and* connect the whole thing to JACK as just another audio source. 1.4 MPlayer http://www.mplayerhq.hu/ MPlayer is a multimedia player for Linux. It supports audio and video playback, tons of media formats, lots of output devices and types, and has more features than I can adequately count here. For our purposes, we'll simply be chaining it to JACK as an audio source (letting it do its own thing for video, if needed) so we can crossfade between it and the filler music XMMS provides. 1.5 Tom's Audio Processing LADSPA Plugins http://tap-plugins.sourceforge.net/ This set
Re: [Pykaraoke-discuss] PyKaraoke v0.4.2
On 4/2/06, Kelvin Lawson <[EMAIL PROTECTED]> wrote: > Hey Will, long time no speak. Heh, I've been really busy :) > > I've been experimenting a lot lately with trying to get pitch shifting > > working, and I've made a pleasant discovery that, at least in Linux, > > makes it a snap to implement. I'm totally jazzed about this :) > > Yeah I spotted this on your blog the other day. Kudos! This is a great > solution as it saves reinventing the wheel. Any chance you could post a > little HOWTO to the list on setting this up? :-) It's a good solution for Linux, though I don't think JACK or the other stuff runs on Win32 though; it's *possible* you could build a similar kind of toolchain on Win32 though with whatever SDL is using for sound delivery. I'd be glad to write up a howto. It was fairly easy to do once I figured out the little gotchas. I'll post it in the next few days. > > More directly PyKaraoke-related, I wrote a patch against v0.3 that > > added a configurable on-screen display (showing player status, time in > > the song, etc.); anybody at all interested in that kind of feature, or > > am I just being a showoff at the local shows? :) > > > > I'd need to probably refactor it to work properly in v0.4 since that > > introduced the segmented display scheme; though I was just overlaying > > FreeType font stuff onto the buffer right before it gets flushed to > > the display device, so it may still just apply and work. > > If you're modifying the cdgSurfArray, then it just now needs to set > appropriate bitfields in UpdatedTiles to specify which tiles have been > modified. Then cdgDisplayUpdate() will automatically work on only the > updated tiles. If it's not obvious what to do then I'd be happy to do > the merge. > > Thinking about it, it's probably not appropriate to blit the text into > cdgSurfArray as it would get scrolled if there was any scrolling in the > CDG. Better to do this to the unscaled_tiles array immediately before > scaling and output. This way it won't be left hanging around in the main > cdgSurfArray for use by the scrolling code. The way I'd gotten it working before wasn't to write on the cdgSurfArray, just on the finished buffer right before it got sent to the screen. I think :) If that's still true, then yeah, I just need to update the UpdatedTiles chunk to tell it I've written changes there. Of course, the way I was doing it, I was just drawing the text on every frame anyway. I think I saved the rendered text and only changed *it* when necessary, then blitted it onto the finished output buffer right before it got displayed. Bleh. I need to dig some more to remember how I did it :) -- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family! --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] PyKaraoke v0.4.2
On 3/29/06, Kelvin Lawson <[EMAIL PROTECTED]> wrote: > That reminds me... I've had v0.4.2 ready to go for some time now. Tthe > Linux/source release is on Sourceforge now. The Windows installer will > follow later. > > Changes in this release are: > > * pycdg: Support starting files without .cdg extension for tab-completion > * Fix Border Preset commands (don't clear entire screen) > * pycdg: play CDGs without an MP3 file for test purposes > * pycdg: Fix FutureWarning on 0xs > * pycdg: Fix option type 'str' for optparse > * GUI: Reorder Playlist (drag & drop) > * GUI: Drag and drop from Search View to Playlist > * GUI: Drag and drop from Folder View to Playlist > * GUI: Made some of the GUI features reusable by other scripts (Craig Rindy) > * GUI: Fix non-ASCII characters in filenames (Craig Rindy) > > Cheers, > Kelvin. Sweet! I've been experimenting a lot lately with trying to get pitch shifting working, and I've made a pleasant discovery that, at least in Linux, makes it a snap to implement. I'm totally jazzed about this :) Since PyKaraoke is using Pygame, which uses SDL, PyKaraoke automatically uses the "default" ALSA sound device when ALSA is the configured sound system on the machine. Enter the Jack Audio Connection Kit: I got that thing fired up, set a Jack module as the default ALSA device (much simpler than it sounds), then configure a Patchbay kit (about a two minute process now that I'm used to it :) so that a sound processor gets exclusive access to the sound card, everything talks to the sound processor (PyKaraoke, MPlayer, etc.), XMMS feeds into the sound processor's Crossfader channel, and suddenly I have all-digital crossfading between sound sources and pitch shifting for PyKaraoke. Heh. Yay :) More directly PyKaraoke-related, I wrote a patch against v0.3 that added a configurable on-screen display (showing player status, time in the song, etc.); anybody at all interested in that kind of feature, or am I just being a showoff at the local shows? :) I'd need to probably refactor it to work properly in v0.4 since that introduced the segmented display scheme; though I was just overlaying FreeType font stuff onto the buffer right before it gets flushed to the display device, so it may still just apply and work. -- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family! --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] CAVS' "Super CD+G" format
On 12/20/05, Kelvin Lawson <[EMAIL PROTECTED]> wrote: > > The problem, as I note, is that the commercial ones are packaged in > > this encrypted .DAT file, that I'm going to have to crack first. > > OK well let us know if you find time to look further into it. After I > get this new release out I'd like to concentrate on getting pycdg > working with pymedia and libsoundtouch. After that lrc, kok, cavs and > The World :-) Yeah, about that, SWIG is seriously pissing me off. Can't make it work, probably because I'm just an idiot (and very rusty w/C), so someone else gets a turn now :) > >>pykaraoke.wikispaces.com > >> > > Aw. Not MediaWiki. Denied. > > Heh, well it was a question of time and benefit. Saved a couple of hours > of setting up mysql and mediawiki at my hosting providers. Hey don't knock it, I love MediaWiki :) I run it on my sites too :) -- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family! --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click ___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] Re: FINALLY -- ghod I hate SuSE
On 12/19/05, Kelvin Lawson <[EMAIL PROTECTED]> wrote: > Hi Jay, > > Thanks for the feedback. So do you think this is an improvement on the > previous performance? If it's difficult to tell with the new 1/4 second > display-dropping code then let me know and I'll take it out. > > If it's an improvement then maybe the thing to do is divide the screen > into smaller segments. > > I've made a few updates tonight, if you could help by trying them out > that would be great. Although the last version only scaled the modified > tiles, it still did a full update() on the entire screen. This one only > updates the modified tile. > > I've also removed a small delay that was in there to reduce CPU load > (which stops it constantly polling for the current song time). I'm > wondering whether some systems can hit this and block for a long time, > doing no work at all. It will take your CPU load up to 100% if it wasn't > already. > > I also added some profiling code in there using the hotshot module. It > hasn't turned out to be useful unfortunately - according to the > documentation it doesn't play well with threads. The accumulated time it > spews out is totally incorrect for instance. I've disabled it in there > for now. > > Cheers, > Kelvin. > > > > At the 15 fps you set it to, it can just about keep up with SC8119-1, > > but I can see the pauses. Again, this is at: > > > > screen #0: > > print screen:no > > dimensions:1280x1024 pixels (361x271 millimeters) > > resolution:90x96 dots per inch > > depths (7):24, 1, 4, 8, 15, 16, 32 > > root window id:0x60 > > depth of root window:24 planes > > number of colormaps:minimum 1, maximum 1 > > default colormap:0x20 > > default number of colormap cells:256 > > preallocated pixels:black 0, white 16777215 > > options:backing-store NO, save-unders NO > > largest cursor:64x64 > > current input event mask:0xfa4031 > > KeyPressMask EnterWindowMask LeaveWindowMask > > KeymapStateMask StructureNotifyMask > > SubstructureNotifyMask > > SubstructureRedirectMask FocusChangeMask > > PropertyChangeMask > > ColormapChangeMask > > number of visuals:8 > > default visual id: 0x23 > > visual: > > visual id:0x23 > > class:TrueColor > > depth:24 planes > > available colormap entries:256 per subfield > > red, green, blue masks:0xff, 0xff00, 0xff > > significant bits in color specification:8 bits > > > > Hope that's informative enough. Have you profiled it? Can you profile > > it? Can I profile it? :-) [swallows tongue] You're running this at 1280x1024? Heh :) I'd been running shows at 1024x768 and not quite using full screen. Hrmmm... Kelvin, I'll give the new code a try too. In full screen 640x480, btw, the thing is blazing fast. Same with 800x600. -- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family! --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click ___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] *Creating* CDG files
On 12/19/05, William Ferrell <[EMAIL PROTECTED]> wrote: > Essentially, there are eight instructions in the command set: [then I list nine] Duh, I can count :P --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click ___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] *Creating* CDG files
On 12/19/05, Jay R. Ashworth <[EMAIL PROTECTED]> wrote: > So, let's take a short right turn, shall we, and muse on a related > topic. > > How hard would it be to create a media=type plug in for something like > Audacity or one of the other multi-track audio editors for Linux which > could be used to *build* CDG tracks? > > Karaoke Builder Studio is nice... but it's almost $200. > > PowerKaraoke *looks* nice (though I haven't played with it)... but it's > still $90. > > I suspect Kelvin has a feel for how complex the tracks are, having > rendered them; any thoughts on this? It's not incredibly *hard*, but it's not really simple either. CD+Graphics (CD+G) is a bolt-on extension to the CD Audio format, that rides in the usually unused 6 subchannels (out of 8) on the typical CD. This page describes it in excruciating detail: http://jbum.com/cdg_revealed.html Essentially, there are eight instructions in the command set: 1) Set the screen to color X (clear screen to color) 2) Set the border to color X (clear border to color) 3) Load color table entries 0-7 4) Load color table entries 8-16 5) Set the transparent color 6) Scroll (filling new area with color) 7) Scroll (wrapping data around) 8) Draw tile (normal) 9) Draw tile (XOR) There's no facility to "write this string X at position Y," you get to blit data, tiny chunks at a time, to the screen. Yay :) Anyway, the format's pretty simple, so generating the final output isn't too hard. It's coming up with what to show in the first place that's the challenge :) It basically just means coming up with a decent palette (fairly easy), picking a readable but fast-to-display font, and timing things so the words are on the screen *before* they need to be sung and getting them to highlight as they're sung. 'tis fun :) Kelvin probably has more input, too :) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click ___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] FINALLY -- ghod I hate SuSE
On 12/12/05, Jay R. Ashworth <[EMAIL PROTECTED]> wrote: > On Mon, Dec 12, 2005 at 03:18:27PM -0700, William Ferrell wrote: > > > Well, only in that they do 2 fields per frame. :-) > > > > You're right; I paid more attention to how it performed at native > > resolution (non-full screen, no scaling) at 30 FPS versus 60 FPS and > > there's no discernable difference. 30 FPS is fine, even at 1024x768 > > this machine can handle it with only about 35% CPU usage. > > > > I'd recommend changing the default to 30 instead of 60 :) > > Well, frankly, 15 seemed good enough on the Dangerous discs I was working > on... It's *okay*, but it doesn't look as smooth as 30FPS does. > > Interesting thought; my only concern with using Xvnc is speed -- > > certainly OpenGL hardware acceleration isn't available via Xvnc, so > > the spiffy visualizations I run wouldn't work properly, nor would > > video playback (unless I've missed something major in VNC development > > :). > > True. > > But we're not *playing* video. I am, and yes we are :) Remember the pykaraoke suite includes an MPEG player :) > > However, I'm curious if anyone here knows how to snag the right-hand > > "half" of my two-screen-wide X server desktop and create a "preview" > > of what it's showing in a small window on the left side. Enlightenment > > can do something similar with its "pager" feature but that's horribly > > slow and too small to be useful. > > I believe you'll find it easier to back up and do it the other way: two > screens (:0.0 and :0.1, and pick up 0.1's traffic into a preview window). Oooh, how does this work? I'm quite interested in getting something like this going. > > See if 30 FPS is any better. > > As noted, I scaled it back to 5fps before it finally quit falling behind. Crud. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click ___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] FINALLY -- ghod I hate SuSE
On 12/12/05, Jay R. Ashworth <[EMAIL PROTECTED]> wrote: > On Mon, Dec 12, 2005 at 04:56:28AM -0700, William Ferrell wrote: > > On 12/11/05, Kelvin Lawson <[EMAIL PROTECTED]> wrote: > > > The CPU horsepower is heavily affected by the display update rate, I > > > think v0.4 went out with a default 60 frames per second. I've lowered > > > this to 10fps in CVS. To lower it in your installation, search for "fps" > > > in pycdg.py. > > > > The only problem with this is that the FPS is actually somewhat > > important; 15 fps is a bare minimum (from the testing on different > > tracks I've tried it with) for usable singing (it seems "jumpy" even > > at 15 FPS, though it's servicable). 30 FPS is definitely better, and > > 60 FPS is what the hardware players I've worked with produce. > > Well, only in that they do 2 fields per frame. :-) You're right; I paid more attention to how it performed at native resolution (non-full screen, no scaling) at 30 FPS versus 60 FPS and there's no discernable difference. 30 FPS is fine, even at 1024x768 this machine can handle it with only about 35% CPU usage. I'd recommend changing the default to 30 instead of 60 :) Thanks for the reminder, Jay :) I forgot TVs do that 2 fields trick. > > > I made a development version that allows you to send to another X > > > display, but not dual-display yet. Dual-display is going to need some > > > architectural changes... something like a single audio playback and > > > syncing module that sends the display data to other display processes. > > > There's no built-in support in pygame for selecting X displays so it > > > would mean running a new python process with DISPLAY= in front. > > > > Don't forget about xinerama-style support -- one desktop stretched > > across two physical display devices. This is what I use now (the > > notebook display is used for my stuff during a show, then the > > VGA-to-NTSC adapter showing the other half of the desktop is used for > > the "who's up" cards, video clips, etc. > > I don't know that I'll have Xinerama support on the Tritton USB VGA > dongles I'll need to use; I plan to have 3 or 4 channels of video going > simultaneously. I *may* get by with one X server; I may not. > > Optimally, I'd like to have 4 Xvnc servers and 4 real ones; if one gets > locked up mid show, it's more likely to be a hardware server; that wasy > i could restart it without breaking the show. I don't know that I'll > be doing that on an laptop, of course. Interesting thought; my only concern with using Xvnc is speed -- certainly OpenGL hardware acceleration isn't available via Xvnc, so the spiffy visualizations I run wouldn't work properly, nor would video playback (unless I've missed something major in VNC development :). However, I'm curious if anyone here knows how to snag the right-hand "half" of my two-screen-wide X server desktop and create a "preview" of what it's showing in a small window on the left side. Enlightenment can do something similar with its "pager" feature but that's horribly slow and too small to be useful. > > pycdg.py plays along just fine by specifying the correct geometry and > > position, too. I can routinely squeeze 50 FPS out of it at 800x600. If > > I try for 60 FPS, it loses sync with the audio and isn't usable. > > Mine is much less happy than that, but, of course, that's at 1280x1024. See if 30 FPS is any better. > Can "fullscreen" mode change the scan rate of the X server? Set it to > 640x480x8, and the problem would likely evaporate. Yes, full screen mode will switch your display resolution if it can match a mode to your options; try this: pycdg.py -w 640 -h 480 -f -s 30 file.cdg That'll run it at full screen, 640x480, at 30FPS. You should even be able to get 60 FPS out of it, not that I can now see much difference between 30 and 60 :) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click ___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] FINALLY -- ghod I hate SuSE
On 12/11/05, Kelvin Lawson <[EMAIL PROTECTED]> wrote: > Hi Jay, > > > I note that it doesn't handle full-screen well (1280x1024), speedwise; > > is there something I should be doing there? > > The CPU horsepower is heavily affected by the display update rate, I > think v0.4 went out with a default 60 frames per second. I've lowered > this to 10fps in CVS. To lower it in your installation, search for "fps" > in pycdg.py. The only problem with this is that the FPS is actually somewhat important; 15 fps is a bare minimum (from the testing on different tracks I've tried it with) for usable singing (it seems "jumpy" even at 15 FPS, though it's servicable). 30 FPS is definitely better, and 60 FPS is what the hardware players I've worked with produce. > Will also committed a mod in CVS to use hardware acceleration if > available in full-screen mode - sounds like it would be worth giving > that a go as well. It's enabled by default in CVS but it doesn't actually seem to help at all (that I can detect). It may just not be working or I may have set something up incorrectly. Having more pairs of eyes looking that over would be helpful :) > What speed CPU are you using by the way? The notebook I now use for shows is an AMD Sempron 1.6GHz. > > My production environment will be a little tiny window on my KJ > > display, and probably 640x480x8 on the playback monitor (are we doing > > dual-monitor yet? Or will I have to do an X-splice somehow?); will > > that be fast enough to keep up? > > I made a development version that allows you to send to another X > display, but not dual-display yet. Dual-display is going to need some > architectural changes... something like a single audio playback and > syncing module that sends the display data to other display processes. > There's no built-in support in pygame for selecting X displays so it > would mean running a new python process with DISPLAY= in front. Don't forget about xinerama-style support -- one desktop stretched across two physical display devices. This is what I use now (the notebook display is used for my stuff during a show, then the VGA-to-NTSC adapter showing the other half of the desktop is used for the "who's up" cards, video clips, etc. pycdg.py plays along just fine by specifying the correct geometry and position, too. I can routinely squeeze 50 FPS out of it at 800x600. If I try for 60 FPS, it loses sync with the audio and isn't usable. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click ___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] FINALLY -- ghod I hate SuSE
On 12/11/05, Jay R. Ashworth <[EMAIL PROTECTED]> wrote: > I have it working now. > > I had to build SDL from tarball source -- the RPM wouldn't even > ./configure, much less build a binary (which was my preferred > approach). > > Building it required installing slang-devel and smpeg-devel, both of > which were in the SuSE 9.3 collection, and, I don't *think*, anything > else. Evil. Just evil :) > I note that it doesn't handle full-screen well (1280x1024), speedwise; > is there something I should be doing there? Yeah, I've noticed this, too; I think it's SDL having problems; the notebook I'm running this thing on now has hardware-accelerated OpenGL and if I try to run it higher than 800x600 at more than 30 fps, it crawls and actually gets out of sync. I tried adding pygame.HWSURFACE | pygame.DOUBLEBUF and similar options to the cdgDisplayOptions variable, but it didn't seem to make anything faster. Not sure what's slowing it down. Could just be the scaling method; is there a way to scale *without* turning on smoothing? That'd be handy. > My production environment will be a little tiny window on my KJ > display, and probably 640x480x8 on the playback monitor (are we doing > dual-monitor yet? Or will I have to do an X-splice somehow?); will > that be fast enough to keep up? I'm doing dual-monitor just fine with pycdg.py: pycdg.py -x 800 -y 0 -w 800 -h 600 -s 60 track03.cdg Works just fine on my second monitor (xinerama, baby :) > And, finally, I note that my rip was kinda messy. Will cdparanoia > properly extract the subcode? Is there error correction *on* the > subcode? Or am I going to have to preview all 4000 tracks before I > turn them lose? It depends on what mode(s) your CD reader rips in -- if you can rip cooked instead of raw, I think that makes things better. No real proof of this yet though :) > (Will: there's another button for the interface: "Problem with track -- > rerip" :-) Noted. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click ___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] Installer
On 12/1/05, Kelvin Lawson <[EMAIL PROTECTED]> wrote: > Hi Folks, > > I've used python distutils to make a simple install script for > PyKaraoke. Hopefully this should make it easier to create the various > packages we need for the distro package managers. I'll test this after tonight's karaoke show. I'd try it now, but I've got an hour 'till setup time and I don't want to change or risk breaking anything right before a show starts. I hate wiping egg off my face :) -- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family! --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click ___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] DJ/KJ in Denver Checking In
On 11/28/05, Kelvin Lawson <[EMAIL PROTECTED]> wrote: > > I think that I've never *ever* seen a commercial CDG that scrolls. > > > > Ever. > > > > KBS will create them, and I should have that in a week or two. But I > > wouldn't worry *too* much about it. > > I've got one from "Doctor Music", that I used for testing the scrolling > code. Can't recall if I've seen it on any others though. > > Kelvin. How "expensive" is it just to start from byte 0 of the CDG instructions and run every command in order internally up to the current seek time, then blit the result? I had been assuming that scaling/drawing the output itself is what took time, and that on the internal drawing surface it was nearly instantaneous and painless. Am I just nuts? :) Either way, I would think that going back to the last memory preset would do the trick; doesn't that clear out *everything,* not just the visible area? -- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family! --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click ___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] DJ/KJ in Denver Checking In
On 11/27/05, Jay R. Ashworth <[EMAIL PROTECTED]> wrote: > On Sun, Nov 27, 2005 at 02:29:11PM -0700, William Ferrell wrote: > >I'm actually keen to implement an internal MP3/OGG/WAV player > >anyway; we need that to be able to do pitch shifting and time > >munging, and then we get seeking (coding the CDG seeking part will > >be fun ;). > > Don't forget FLAC and MPEG (being able to rip CD-V's would be cool, > too, and, for that matter, the dedicated could rip LaserDiscs with a > capture card. I think MPEG playback is done elsewhere (I could be wrong and I haven't checked) but I believe it's already supported. FLAC is just a matter of adding the correct library. > Is the proper approach here to locate the already-extant project which > is closest to what we need, and submit patches? Probably. That's Kelvin's call though :) > And, BTW, Will; could you check your mailer for an HTML knob, and flip > it off? Heh. You said "knob." It is annoying that gmail doesn't appear to have a setting for that; there is, however, a "plain text" thing buried amongst the compose window options. Didn't even notice it was sending HTML by default. Yuck. -- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family! --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click ___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] DJ/KJ in Denver Checking In
On 11/26/05, Christopher A. Williams <[EMAIL PROTECTED]> wrote: Since everything in 0.4 is self-contained already, if you keep thecurrent files in their own folder, it should work. As a first step, Iwould suggest placing what would be the unzipped files in somethinglike /usr/local/PyKaraoke and creating a launcher for them. I did this on my FC4 system and it seems to work just fine - at least the softwarelaunches without complaints. Again, this is just unqualified me thinkingof a stop-gap until the other details could be worked out. Doesn't the "Linux Standard Base" (or whatever the [EMAIL PROTECTED] it's called) provide some standard for where apps go? PyKaraoke and cdgtools are small enough that they can reasonably just live in /usr/bin. Definitely keep me posted on your progress. Since we have a dependencyon MP3 support in SDL, Fedora Core becomes a little more tricky. The Livna.org repository seems most appropriate because they include apackage called SDL_Sound that adds MP3 libraries to SDL. They alsoalready host most of the needed python packages. I'm actually keen to implement an internal MP3/OGG/WAV player anyway; we need that to be able to do pitch shifting and time munging, and then we get seeking (coding the CDG seeking part will be fun ;). Since that was the case, I submitted package requests via Livna'sBugzilla system for both CDG Tools and PyKaraoke today and included the source files as attachments to the bugs. It seems they feel bestqualified to build their own packages, but forwarding them a source RPMdefinitely wouldn't hurt. As soon as I hear back from them, I'll posthere. Cool! Thanks. -- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family!
Re: [Pykaraoke-discuss] DJ/KJ in Denver Checking In
On 11/26/05, Jay R. Ashworth <[EMAIL PROTECTED]> wrote: On Sat, Nov 26, 2005 at 02:54:56PM -0700, William Ferrell wrote:>Definitely. Red Hat and derivatives are still the prevalent distros.For sufficiently large values of "derivatives". Hehehehe yeah :) >It *should* [knocks wood] be a matter of just copying the programs>themselves (all the .py files) to /usr/bin or /usr/local/bin, and>dropping the modules used into /usr/lib/python2.[0-4]/site-packages>... but it could still get interesting anyway :)The number one issue is making sure the location in the shebang line points to the real interpreter; if you get that right, you can take the.py extensions off the user binaries and they'll still run. Whetheryou should put them in a directory that's on the path is a maintainer call. Behold this spiffy magic: #!/usr/bin/env python As far as I know, every distro sets up "env" to spew the correct location of python (the above shebang has never failed to work for me on any system I've tried it on). -- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family!
Re: [Pykaraoke-discuss] DJ/KJ in Denver Checking In
On 11/26/05, Kelvin Lawson <[EMAIL PROTECTED]> wrote: >>Right now, I'm working on what I can do to help sponsor PyKaraoke and>>CDG Tools in one of the Fedora Core repositories. That means creating an>>RPM and sponsoring the package. I'm working on both. That said, I'm not >>exactly an expert on RPM packaging, but am willing to learn more.>> I'm hoping myself to to that for SuSE (9.3, and probably some other> releases)...Fabulous, music to my ears :-) As I was saying to Chris, I tend to only install software from my distro's package manager, so I've always feltpackaging would help PyKaraoke reach a wider audience. Definitely. Red Hat and derivatives are still the prevalent distros. I'm planning to create packages for Debian/Ubuntu and Gentoo, because Ihave those installed here. Any help folk can give me for other distros would be much appreciated. It's probably worth waiting for me to get thefirst package done, as currently there is no install procedure forPyKaraoke at all. It's unzip anywhere and go. I guess I'll need tocreate an install script or something to put everything in the appropriate places. I'll let you both know when I've figured that stuff out. It *should* [knocks wood] be a matter of just copying the programs themselves (all the .py files) to /usr/bin or /usr/local/bin, and dropping the modules used into /usr/lib/python2.[0-4]/site-packages ... but it could still get interesting anyway :) -- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family!
Re: [Pykaraoke-discuss] DJ/KJ in Denver Checking In
On 11/26/05, Jay R. Ashworth <[EMAIL PROTECTED]> wrote: It turns out that Will, in Ft Collins (and after the holidays, I hopeI've gotten his name right :-) thinks much the way I do about in-show usability, *and* *is* a coder. :-) Yup, got the name just fine :) > Any ideas would be appreciated. Looking forward to contributing where I> can! Our plans for evening domination are proceeding precisely on schedule. The streets will RUN RED, with the BLOOD OF OUR ENEMIES! Heh. A little too much Sealab 2021 last week, methinks. I'm better now :) -- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family!
Re: [Pykaraoke-discuss] DJ/KJ in Denver Checking In
On 11/26/05, Christopher A. Williams <[EMAIL PROTECTED]> wrote: I run a mobile DJ/KJ service in Denver and have had a couple of e-mailexchanges with Kelvin, which has led me to this list.I've gone through the archives and see there's someone also in Ft.Collins - we should talk sometime. :) Hey, my ears are burning :) Greetings from Fort Collins! Right now, I'm working on what I can do to help sponsor PyKaraoke andCDG Tools in one of the Fedora Core repositories. That means creating an RPM and sponsoring the package. I'm working on both. That said, I'm notexactly an expert on RPM packaging, but am willing to learn more.In terms of technical strengths, I'm much more of a network and systems administration / systems integration guy than a coder, and I also have abase level of knowledge in Usability. I have lots of ideas which I maytry to tee up in time once I have a better feel for what's already being tossed around. My background was similar, though with a definite "this doesn't do what I want, time to write a new one" leaning. Fair warning: network/sysadmin and integration is the gateway drug to coding :) I have confirmed what Fedora Core 4 packages are needed, as well aswhere they come from, to have everything work. Fortunately, you can already get everything you need from the most popular FC repos. Thatshould make the rest of this pretty straight forward - just a matter ofdeciding where things should go, creating a symlink or two and adding menu entries with icons.Any ideas would be appreciated. Looking forward to contributing where Ican! Great to have another contributor! I must sheepishly admit I run Ubuntu on my notebooks (and have two hardware platforms now available for testing -- x86 and amd64) so I should probably be doing something to help package this thing up, too :) Kelvin, consider me a guinea pig for packages (and for packaging the amd64 version, even assuming we *can* do that right now -- pygame-from-CVS won't make the Ubuntu maintainers happy ;) -- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family!
Re: [Pykaraoke-discuss] Re: Little patch to add support for WAV files to pycdg
On 11/17/05, Marcel Portela <[EMAIL PROTECTED]> wrote: Hy guys, sory for de english... >> Well, the issue is checking the disc for a file with an extension of >> unknown case. The same work that my patch is doing must still be >done, >> it'd just be nice to move it outside pycdg.py; I do think there's a >> case-insensitive "find" workalike in Python. I should go look it up >:) >Ah, gotcha. This is for finding the matching audio file.in pycdg.py, you have the code that check your audio file, i've extracted the piece of code below:"""# Check there is a matching mp3 or ogg filevalidexts = ['wav', 'wAv', 'waV', 'wAV','Wav', 'WAv', 'WaV', 'WAV', 'mp3', 'mP3', 'Mp3', 'MP3','ogg', 'oGg', 'ogG', 'oGG','Ogg', 'OGg', 'OgG', 'OGG']matched = 0for ext in validexts:if (os.path.isfile(self.FileName[:-3] + ext)):self.SoundFileName = self.FileName[:-3] + extmatched = 1""" Yeah, I agree this is ugly :) You can do this check with a pythonic way:"""# Check there is a matching mp3 or ogg file - pythonic way validexts = ['wav','mp3','ogg']matched = 0if (self.FileName[-3:].lower() in validexts):self.SoundFileName = self.FileNamematched = 1""" Actually this doesn't quite do it; the purpose of this check is to look at the filesystem for a matching file. It's not enough just to check against the filename we're passed. Remember, self.FileName contains the .cdg passed from the command line; it will never match validexts. -- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family!
Re: [Pykaraoke-discuss] First attempt. Failure. :-} SuSE 9.3
On 11/14/05, Jay R. Ashworth <[EMAIL PROTECTED]> wrote: On Mon, Nov 14, 2005 at 12:16:47PM -0700, William Ferrell wrote:>I've given it some thought; once we get pykaraoke switched over to a>different playback engine (so we can play with the audio stream as it >heads to the sound card), it'd be a matter of getting synced frames>(audio and video) to an encoder. That might be a tad on the difficult>side :) I've never written an encoder before :) And, come to think of it, the pitch and tempo shifting stuff isprobably made *harder* by that... Actually not; pitch/tempo shifting is currently impossible in pycdg because of its use of pygame; we hand pygame's mixer module an MP3, Ogg, or WAV file to play, and it goes and does it. We get *no* chance to muck with the audio it produces at all. Wanting to shorten or lengthen an song *does* make CDG rendering more "interesting" (you're no longer executing 75 packets of instructions per second) but once that wrinkle is ironed out, producing an encoded video of the result remains at the same difficulty level as just doing it without pitch/tempo shifting. > (Obviously, my preferred target would be Vorbis/Theora...)>>Yeah, that'd rock. >I've got a few modifications to make to cdgrip.py, actually. I already>modified it weeks ago to compress ripped audio to Ogg instead of MP3,>but never made it "clean," so I intend to fix that, and I figured>since people like distributing CDG+Audio pairs in archives (.zip,>etc.) and cdg2bin supports extracting them already, the rest of the>toolchain might as well support it too (creating .zip/.tar.bz2>archives during rip, extracting during playback, etc.). Probably couldn't hurt.Sounds like we're building a library. Switching from MP3 to OGG and from .zip to .tar.bz2 saved me 24.736% on a 19.7GB collection of karaoke pairs. The new collection after recompression is 14.8GB in size (savings of 4.9GB). That currently comprises 4,849 songs. Yay :) Incidentally: Kelvin; I've been through much of your python code thelast 24 hours; please let me compliment you on your *insanely* good coding and commenting style. Seconded; that's what made it so easy to quickly learn how the player worked and figure out how to patch it (mostly properly :) to add features I wanted. -- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family!
Re: [Pykaraoke-discuss] First attempt. Failure. :-} SuSE 9.3
On 11/14/05, Jay R. Ashworth <[EMAIL PROTECTED]> wrote: On Mon, Nov 14, 2005 at 09:37:04AM +, Kelvin Lawson wrote:> > File "../pykaraoke-0.3.1/pycdg.py", line 400, in run> > pygame.mixer.music.load(self.SoundFileName)> > error: Module format not recognized >> This is because SuSE helpfully supply the SDL_mixer library without mp3> support. Check out the following:>> http://kibosh.org/pykaraoke/installation.php I'd looked there, but missed that particular note.Of course; something on that laptop's hardware went last night, and nowit will run WinXP, but the X server fades slowly to white on boot. Hey, my old ThinkPad used to pull that trick occasionally. Usually a reboot fixed it; setting a different video mode (bit depth or resolution) sometimes fixed it too. Here's an interesting idea, BTW: have we thought about, instead ofripping to MP3 and CDG files, ripping and then rendering to an MPEG or XVID monolithic file and playing that back? Clearly the renderingwould take time; would we save space in addition to complexity? I've given it some thought; once we get pykaraoke switched over to a different playback engine (so we can play with the audio stream as it heads to the sound card), it'd be a matter of getting synced frames (audio and video) to an encoder. That might be a tad on the difficult side :) I've never written an encoder before :) (Obviously, my preferred target would be Vorbis/Theora...) Yeah, that'd rock. I've got a few modifications to make to cdgrip.py, actually. I already modified it weeks ago to compress ripped audio to Ogg instead of MP3, but never made it "clean," so I intend to fix that, and I figured since people like distributing CDG+Audio pairs in archives (.zip, etc.) and cdg2bin supports extracting them already, the rest of the toolchain might as well support it too (creating .zip/.tar.bz2 archives during rip, extracting during playback, etc.). -- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family!
[Pykaraoke-discuss] Tagging pykaraoke for a new release?
Hey guys, It occured to me we should probably tag the pykaraoke build currently in CVS for the v0.4 release (because I have more stuff I want to bang on and commit to CVS, but that shouldn't be released in v0.4 :); anyone object if I do so? Once it's tagged, there's a CVS command (that escapes me at the moment, but I'm looking it up right after writing this mail :)) to grab a specific tagged version of a project so it can be released. Lemme know what you think, no rush; I've got plenty of stuff to do in the meantime :)-- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family!
Re: [Pykaraoke-discuss] PyKaraoke v0.4
On 11/9/05, Kelvin Lawson <[EMAIL PROTECTED]> wrote: Hi Will,I've just incorporated your patches into CVS. As it's bang up to datenow, feel free to commit at will from now on :-)If you could check it over before I do the release that would be great.I made a few small mods, mainly to keep the API compatible with the PyKaraoke GUI. I've made it possible to call the API with None for theoptions object, so that other Python modules can import it and use itwithout building an optparse object externally. I need to modify the KAR and MPG players to support the new optparse options, but I'll leave thatfor a future release. The changes look fine; it runs fine on this box. I'd like to add direct support for archives in pycdg.py as well (some players I've seen on Windows can directly support ZIP at least; if I drag in the stuff from cdg2bin that adds support for archives, we'll have 'em beat with ZIP, .tar.gz, and .tar.bz2 support :) BTW the archive support only uses zipfile and tarfile, both standard modules that ship with Python. The way current support is written, they're only imported when needed, so even on systems that don't support them for whatever reason, stuff will still work (you just have to extract it yourself). But that can be in the next release; this looks good to go :) -- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family!
Re: [Pykaraoke-discuss] CD+G CD image mastering tool nearly finished
On 11/9/05, Kelvin Lawson <[EMAIL PROTECTED]> wrote: > Committed (and README updated as well).Excellent, I'll line this up for release shortly after the newPyKaraoke. Thanks for your efforts, this is exactly what cdgtools needed.> It would be "easier" to write a function that mangles 96 bytes (one > frame's worth) at a time; then you'd just have this:The spanner in the works is that the interleaving process spews thebytes into adjacent sectors, so it's not a straight "96 bytes in, 96bytes out" process. I'll have a look at the best way to wedge it in anyway. Got it. Best then is to mangle all the data at once then and sort out how to grab 96 bytes at a time of the result for writing during the interlacing phase. Spiffy, though, glad you've got a handle on it :) -- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family!
Re: [Pykaraoke-discuss] CD+G CD image mastering tool nearly finished
On 11/9/05, Kelvin Lawson <[EMAIL PROTECTED]> wrote: > Yay! Let me know when it's populated; I added support for archives this > morning. The disc I burned with it last night worked correctly on a> standalone CD+G player, so the tool is confirmed working.Good stuff. I've just populated CVS with the v0.2 release, so you should be good to go. Committed (and README updated as well). > The only thing it's missing is support for that raw/interleaved mode; my > *drive* supports the writing scheme, I just don't know how to *image* it> :) Anyway, just search in the code for "not yet supported" and you'll> find the only missing piece of functionality. Command-line options are > already present for raw mode. It just needs the magic code added. I> assume it's something that can be done on a per-frame basis and can just> be added inside the main interleaving loop; if not, it could be more > "interesting" to implement.Note sure what you mean by per-frame? I was thinking of passing atrack's worth of BIN data to an Interleave() function which rearrangesthe whole track's BIN data in one go. Something like:for track in tracks: pcmdata = mp3DecodeFromFile(track.mp3_file) cdgdata = cdgReadFromFile(track.cdg_file) if interleave_mode: cdgdata = Interleave(cdgdata) AddToBinFile(pcmdata, cdgdata) Close; actually produce_bin() is the call that does the gruntwork, but it reads straight from files (it doesn't slurp up everything into memory all at once; it works from disk). It does accept a "raw" flag but currently ignores it; I guess you could alter it so that if "raw" set to "true" it just loads in the whole CDG file first, does its mangling, then write out that data instead of reading from a cooked CDG file 96 bytes at a time. Have a look at the code; it should be more clear how things work there once you look at it :) It would be "easier" to write a function that mangles 96 bytes (one frame's worth) at a time; then you'd just have this: Instead of: binfile.write(cdg) Use: if rawbin: binfile.write(reinterleave_cdg(cdg)) else: binfile.write(cdg) It's your call though, do as you wish with it :)-- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family!
Re: [Pykaraoke-discuss] CD+G CD image mastering tool nearly finished
On 11/9/05, Jay R. Ashworth <[EMAIL PROTECTED]> wrote: On Wed, Nov 09, 2005 at 10:56:11AM -0700, William Ferrell wrote:>Yay! Let me know when it's populated; I added support for archives>this morning. The disc I burned with it last night worked correctly on>a standalone CD+G player, so the tool is confirmed working.No, it's not. :-) When it's played successfully on 4 or 5 different brands of players,*then* it's confirmed.Do you know why Sonic Solutions' professional DVD authoring softwarecosts $30k+?It's that room. You know, the one with the 400 different consumer DVD players that they test new versions against before they release them? *sigh* Repetition is fun. Again: this is *not* an authoring app. This is an *imaging* app; it takes existing, already-working CDG data and matching audio, and prepares a redbook audio compliant image with R-W subchannel data compliant with the CD+G extensions to redbook. The image can be passed to cdrdao to produce a disc suitable for playback on standalone equipment. While it has "only" been tested on a single brand of standalone CD+G player, it can be further demonstrated to be working properly by passing its output to cdgtools' cdgrip.py or any available Windows CD+G ripper/encoder -- such tools correctly extract the data as if it had been ripped from a real disc. Taking the testing further, a disc burned with an image made by this tool can be ripped by any CD+G ripping app (on Windows or Unix) to produce working, glitch-free results. Given the age (old) and temperament (picky; glitches even on most real, pressed (non-burned) discs) of the player available to me for testing, and its behavior towards the disc I burned last night, I'm confident in the compliance of the images this tool produces. This is now essentially a replacement for the "MP3+G Toolz" suite by ActiveASP Software (their software is written for .NET, naturally Windows-only). -- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family!
Re: [Pykaraoke-discuss] CD+G CD image mastering tool nearly finished
On 11/9/05, Kelvin Lawson <[EMAIL PROTECTED]> wrote: Hey Will,> Just to throw a quick teaser out there, I thought I'd mention I've got> that tool I'd talked about to convert CDG+MP3/OGG to a cdrdao-compatible> CD image and TOC/cue sheet mostly finished. This is excellent news. I've got an interleaved/raw-mode drive here soyou can leave that job for me if you like. Regardless, this is a greatpiece of software without archive support or interleaved mode support. I've just added you to the cdgtools project at Sourceforge. I neverpopulated the SF CVS for cdgtools so it's currently empty. I'll check inthe latest release (v0.2), which is fully up to date. Yay! Let me know when it's populated; I added support for archives this morning. The disc I burned with it last night worked correctly on a standalone CD+G player, so the tool is confirmed working. The only thing it's missing is support for that raw/interleaved mode; my *drive* supports the writing scheme, I just don't know how to *image* it :) Anyway, just search in the code for "not yet supported" and you'll find the only missing piece of functionality. Command-line options are already present for raw mode. It just needs the magic code added. I assume it's something that can be done on a per-frame basis and can just be added inside the main interleaving loop; if not, it could be more "interesting" to implement. -- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family!
Re: [Pykaraoke-discuss] CD+G CD image mastering tool nearly finished
On 11/8/05, Jay R. Ashworth <[EMAIL PROTECTED]> wrote: On Tue, Nov 08, 2005 at 07:22:54PM -0700, William Ferrell wrote:>I've burned a CD it generated tonight and I'll test it at tonight's>karaoke show. If it works on that standalone player, I'll send along >v0.1-pre1 of cdg2bin :)Careful with that word "mastering", buddy. :-) Pthbtbtbtbt! I've not only mastered mastering CD+Gs on Linux, I've frickin' 0wned it, uh, or something. Heh. This isn't a CD+G *authoring* app, mind you; it just takes existing CDG+MP3/OGG tracks and creates images you can burn onto CDs to run in a normal standalone player. Yes, I *am* going to break down and buy KBS, here when I can affordit... I'd talked to the Brit who built it by email once, and it went the way my first email to you did, Will... and then he ran away. Hehehehe! -- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family!
[Pykaraoke-discuss] CD+G CD image mastering tool nearly finished
Hey guys, Just to throw a quick teaser out there, I thought I'd mention I've got that tool I'd talked about to convert CDG+MP3/OGG to a cdrdao-compatible CD image and TOC/cue sheet mostly finished. The only "feature" left to implement is automatically handling archive files (ZIP archives, tarballs, etc.) with the CDG+MP3 or CDG+OGG pairs in them. If you have just sets of files (not archives), it appears to work fine now. Oh, it's also not able to do "raw" images -- it can only produce "cooked" ones currently (which my recorder happens to support :) since I haven't tried to get my brain wrapped around the "deinterlacing" voodoo cdgrip.py does to go from a RW_RAW CD+G track to split audio and CDG data. It may also need an option to toggle whether conversion to big-endian is required (it is required on x86 platforms and AMD64, but not on big-endian architectures) for the sound data. I've burned a CD it generated tonight and I'll test it at tonight's karaoke show. If it works on that standalone player, I'll send along v0.1-pre1 of cdg2bin :)-- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family!
