Libraries

[ex_directory]

Hi all, just started using Wincab recently and love the skinning option, started modding skins already 

I have come over from VMJ and it's good to see an active community, one of the reasons I gave up on VMJ.

However, today I started to transfer my music across from VMJ. I could not find a way to separate my music in to libraries. I use this feature all the time on VMJ, I have a library of eighties, library of 'Party/current', 'Chilled out', 'Kids', 'Christmas'. VMJ supports more than 4 but I have 4 buttons on my cab to select each library (player 2 mame buttons). With VMJ you have one library loaded at a time which is fine as unless you want to do a full search for a song and you can't remember where it is, can't even remember the last time I wanted to do this but i just use windows search.

Anyway, does this feature exist in WinCab, I see the multiple "SongPath" but nothing else?

If not, can this be requested as a feature, even if it is allocated to a hidden key, i.e. not on screen.

Ex

[Chris]

Anyway, does this feature exist in WinCab, I see the multiple "SongPath" but nothing else?

If not, can this be requested as a feature, even if it is allocated to a hidden key, i.e. not on screen.

There is no way to do this yet.  I do recognize it as a needed feature and it is planned.

[ex_directory]

I read somewhere on this forum someone was using a batch file to do this while it is not supported in Wincab directly. Is this a case of editing the .ini and restarting wincab or would that re-init the db and take too long, i.e. multiple wincab install folders would be required?

Chris, thanks so much for replying so soon, you would not believe how refreshing this is compared to VMJ!

Andy

[Chris]

It would work.  You simply start WinCab with the name of the INI-file, like:

WINCAB.EXE JUKEBOX-XMAS.INI

The database would end up with data from all four "libraries" but only those in the current SongPath would show up on the screen.

[ex_directory]

Sounds easy to add a couple of shortcuts to the desktop - will do for now. Also, does not sound too far off being able to add support to the app.

As a matter of interest, would you implment this as a button, e.g. BTN_NEXTLIB, BTN_PREVLIB, BTN_ALLLIB type thing or are you thinking something else?

[Chris]

I'm referring to them as "filters".  The default concept is to be able to pop up a menu to select to filter on decade, genre or artist, but there's also the idea of "user definable" filters that would be equivalent to your Libraries.

There are actually already definitions in the code for BTN_FILTER_SELECT, BTN_FILTER_CLEAR, BTN_FILTER1 through BTN_FILTER10 (for direct access to a particular filter), so BTN_NEXTFILTER and BTN_PREVFILTER should be easy enough.  BTN_FILTER_CLEAR would be equal to your BTN_ALLLIB.

It is not necessarily far off, as there is code in place for parts of itr already.  Really part of the issue is that it wil require a lot of redesign of the structure of jukebox.ini and skins, as I need to design a way to do pop-up dialogs that are completely skinnable that don't interfere with the playing music, can be accessed either through direct keystrokes, joystick, mouse, touchscreen, etc., and can be used for functions other than just selecting a filter.  It really is a major design change.  Also, the way the database is designed, using filters on a large library is slow; I need to either redesign my database to support indexes or put in a proper database backend like SQL.  In fact, I do have the beginninghs of an SQL backend in place based on SQLite but I'm having trouble getting it to compile in DOS.

Thre is actually all kinds of dormant code in DWJukebox for half-finished features: user-definable timers, macro support, switching skins on the fly, multi-line text rendering for long song names, etc.  How much of it will ever see the light of day remains to be seen.

[ex_directory]

Hi Chris,
Sounds like you are combining the ideas of a search and a library into your "filter" idea.

As a suggestion which you may already be doing, you could take this development in parts, the first being to have the concept of filters configured in the .ini, so no dialog box as search but again multiple BTN's to access them. When you talk about Genre's/Libraries then this will be a limited set for 'most' people so you get away with pre-configuring option, obviously the search really requires the pop-up dialog. That way you can deal with the skinning problem later.

With regards to the database issue, I guess you have a proprietary database solution in place at the moment, changing backend for one feature sounds like a lot of work. Is your database solution causing you problems in other areas? I once developed a proprietary database and later had to add indexes for sorting/filtering. I opted to use memory, loading the database in first, then using several passes of the full db to create new lists (pointers) in memory to the original master list.

Hey, don't talk to me about dormant code, I have been developing the same system (which is also live) since 1994 - my day job. Every now and then dormant (or supposedly dormant) code gets in the way. And then you are caught between we may need this one day so I'll need to spend time to keep it working / remove it to be asked for it six months later! 

May I say how impressed I am with wincab so far, from downloading to adding music to mod'ing an existing skin to match the colours of my cab was done in about 45 mins. Was used extensively on Saturday night and even after I give a quick demo I normally get questions, how do I scroll down again, how do I add a track, ..., not one question - cool 

[Chris]

As a suggestion which you may already be doing, you could take this development in parts, the first being to have the concept of filters configured in the .ini, so no dialog box as search but again multiple BTN's to access them. When you talk about Genre's/Libraries then this will be a limited set for 'most' people so you get away with pre-configuring option, obviously the search really requires the pop-up dialog. That way you can deal with the skinning problem later.

That is essentially exactly how it is planned to work.  The dialog only appears if you press BTN_FILTER_SELECT, which would then list all the predefined filters or allow you to create a filter on the fly.  This is a replacement for a full-on search, which would require an full on-screen keyboard.

With regards to the database issue, I guess you have a proprietary database solution in place at the moment, changing backend for one feature sounds like a lot of work. Is your database solution causing you problems in other areas? I once developed a proprietary database and later had to add indexes for sorting/filtering. I opted to use memory, loading the database in first, then using several passes of the full db to create new lists (pointers) in memory to the original master list.

My "database solution" isn't even really a database.  The DB file is loaded into memory verbatim as an array of strings.  I have a bunch of helper routines written to access the data as if it were a database.  This works because the data is for the most part read-only; the only data that changes is the play count and it only updates once per play, which is once every three to four minutes.  Obviously this "solution" has serious scalability issues!  In addition, the only real index is the song number.  The path to the song is stored in a separate string array which is rebuilt on every run (that's what's happening when the library rescans on startup), unless the UpdateIndex option is set to False in which case it pre-loads the last path array and just trusts that all the songs are there and in the same place.  (On an unrelated note, when the library is scanned, it is not looking for filenames; it looks at the last six digits of the file size and the first four characters of the filename and when it finds a match it assumes that is the same song.  This allows a library built on DOS with 8.3 filenames to be compatible with a library built on Windows with long file names.  That's why you don't see any file names if you open the database in a text editor.)

To support filters, essentially what I would do is at startup, check to see if either the database or filter definition has changed, and if so pre-scan the entire database to see what matches the filter.  I would also do this for artists, genres and decades: create a separate index file for each possible genre, decade and artist (each one that exists at least once in the database) and pre-populate each with a list of integers representing the song ID's (position in the master string array) of each matching song.  The ID3 specification allows for "artist" and "genre" to contain multiple values, so I have to account for that.  None of this is spectacularly difficult, I just don't know if I want to manually build all the code for these indexes or just put in a proper database engine that will do all this for me and be more scaleable. 

Ironically, the DB engine I'm looking at, SQLite, handles the database the same way I do: each record is a string and the entire database is held in RAM at once.

Either way I need to reorganize something, and once I start doing it I'm gonna break things.  But all database access is virtualized through a couple of helper routines so I'll only have to change the backend, not all the code that accesses it.

May I say how impressed I am with wincab so far, from downloading to adding music to mod'ing an existing skin to match the colours of my cab was done in about 45 mins. Was used extensively on Saturday night and even after I give a quick demo I normally get questions, how do I scroll down again, how do I add a track, ..., not one question - cool 

Glad you like it... thank you for the kind words!

[ex_directory]

Hi Chris,
Have been thinking about this thread for a couple of days, also dug out my old source code hoping it may give me some inspiration...

That is essentially exactly how it is planned to work.  The dialog only appears if you press BTN_FILTER_SELECT, which would then list all the predefined filters or allow you to create a filter on the fly.  This is a replacement for a full-on search, which would require an full on-screen keyboard.

Thought you would be doing that kind of approach.

My "database solution" isn't even really a database.  The DB file is loaded into memory verbatim as an array of strings.  I have a bunch of helper routines written to access the data as if it were a database.  This works because the data is for the most part read-only; the only data that changes is the play count and it only updates once per play, which is once every three to four minutes.  Obviously this "solution" has serious scalability issues!  In addition, the only real index is the song number.  The path to the song is stored in a separate string array which is rebuilt on every run (that's what's happening when the library rescans on startup), unless the UpdateIndex option is set to False in which case it pre-loads the last path array and just trusts that all the songs are there and in the same place.  (On an unrelated note, when the library is scanned, it is not looking for filenames; it looks at the last six digits of the file size and the first four characters of the filename and when it finds a match it assumes that is the same song.  This allows a library built on DOS with 8.3 filenames to be compatible with a library built on Windows with long file names.  That's why you don't see any file names if you open the database in a text editor.)

To support filters, essentially what I would do is at startup, check to see if either the database or filter definition has changed, and if so pre-scan the entire database to see what matches the filter.  I would also do this for artists, genres and decades: create a separate index file for each possible genre, decade and artist (each one that exists at least once in the database) and pre-populate each with a list of integers representing the song ID's (position in the master string array) of each matching song.  The ID3 specification allows for "artist" and "genre" to contain multiple values, so I have to account for that.  None of this is spectacularly difficult, I just don't know if I want to manually build all the code for these indexes or just put in a proper database engine that will do all this for me and be more scaleable. 

Ironically, the DB engine I'm looking at, SQLite, handles the database the same way I do: each record is a string and the entire database is held in RAM at once.

Either way I need to reorganize something, and once I start doing it I'm gonna break things.  But all database access is virtualized through a couple of helper routines so I'll only have to change the backend, not all the code that accesses it.

Hmmm, I see your problems with this. Unfortunately in my program that I wrote I was not very innovative...

I essentially had the same thing - a large array of information loaded from file indexed by position in the array. For the most part I was using the whole array at once, but i then added functionality for which I needed to identify start points, if you like the start of chapters, so I did this by creating a separate integer array where each item in the array provided a number which was the start point of the chapter in the master array. The index of this array effectively the chapter number.

The next problem I had was I wanted to be able to view the data by categories which could be selected by the user and each category included a set of pages in the master array that were from several different chapters (I am using books as an analogy - actually had nothing to do with books!). I did this by creating an array per category and that array was simply of list of numbers that referred to the index in the original array again.

To make a further analogy back to wincab, if your database is sorted alphabetically (which I think it is) then your chapters would be letters of the alphabet. This gives you a quick jump to position when searching by artist - but not song.

The list of categories is the same as genres, i.e. the pages are from anywhere in the book, the songs are from anywhere in the database.

Of course I am not telling you anything here because what I have just described you have already said is your proposed solution above anyway! But what I suppose I am saying is that it worked for me, it was fast, relatively small code base and I was not reliant on any 3rd party db.

While not relevant to you as the db is based on user data, it meant I could ship a new single datafile if needed with ease (as all index arrays were created on startup) and could encrypt the datafile.

If it helps, I would say you need to base the design decision on the likely feature creep going forward, if you think this is going to open a door to more feature requests that you want to fulfil then maybe sqlite is the way to go now. Personally I would want to be sure the performance is there with a 3rd party db, it could bring a lot of overhead that you just don't need.

I hope this helps in some way

[ex_directory]

Also, the way the database is designed, using filters on a large library is slow; I need to either redesign my database to support indexes or put in a proper database backend like SQL.  In fact, I do have the beginninghs of an SQL backend in place based on SQLite but I'm having trouble getting it to compile in DOS.

Had a bit of time so looked at the sqlite homepage, looks quite a neat solution, I wonder though how much a good database design is required to get maximum performance from this, it would seem the flatest design is likely to give the most optimal results. There is also a section on compiling for dos which I am sure you have seen here.

Above you say your proposal for using filters in memory will be slow, are you just referring to the startup procedure or the usage  of wincab? I know it costs time but I wonder if a direct performance comparison would yield the sqlite solution to be quicker?

[Chris]

Above you say your proposal for using filters in memory will be slow, are you just referring to the startup procedure or the usage  of wincab? I know it costs time but I wonder if a direct performance comparison would yield the sqlite solution to be quicker?

I'm saying an unindexed filter would be slow on a large library, and the same would be true for SQLite if I don't index it either, although creating SQL indexes is a lot easier.  The big issue is just having to build new database features every time I want to add something, and if I want to do it myself vs. using an SQL-based solution.  It's a matter of "core competencies"... DWJukebox is a jukebox and not a database engine, so do I want to spend my time writing and debugging indexes or adding features to skins?

Really, the only reason I'd even consider it is because I was fortunate enough to think ahead and perform all database access through a couple of functions... makes it easy to drop in.  But it'd be nice to be able to offer "advanced" users the ability to write filters directly in SQL... then there's no limit to what they can do.

The database is actually very flat now.  Effectively there are only three tables: the master song list, a list of integers of "avalable" songs (this is the list I sort and manipulate), and a list of paths.  CD skins have two more tables: a list of album artists and a list of paths to CD cover art.  All of the data tables such as symbol and color names and values, etc. are hard coded; I used to load them from a datafile but then I ran into problems where someone would update the executable but not the datafile, so I just merged it all in. 

[ex_directory]

I'm saying an unindexed filter would be slow on a large library, and the same would be true for SQLite if I don't index it either, although creating SQL indexes is a lot easier.  The big issue is just having to build new database features every time I want to add something, and if I want to do it myself vs. using an SQL-based solution.  It's a matter of "core competencies"... DWJukebox is a jukebox and not a database engine, so do I want to spend my time writing and debugging indexes or adding features to skins?

I understand where you are coming from now. I guess the answer to the issue of amount of debugging/development on indexes would come down to the design of the helper functions etc that support functions to get indexes.

In reality, categories such as decade/genre etc would have permanent indexes that gives benefits of speed of startup (if nothing changed), switching between categories during runtime etc. But a song search etc would probably be a temporary array of song indexes created on the fly. It is probably the performance of the latter that is most important i.e. sql v your own memory based solution.

The only thing I can offer is the similarities to the program I needed to write. If I would have had to support search functions, I would have created function(s) to create indexes on the fly, i think my master array had <10000 items in it, and in terms of a single scan to check each entry for a match be it on one field match or multiple (effectively a sql query), I would have expected to be fast enough that the delay before results were displayed would not be an issue. If the performance was fast enough you could actually have all indexes created on the fly as they are required, this might only mean 1 or 2 more public functions you need to develop to provide that functionality.

We use paradox files at work to maintain a list of records in a buffer so we have state if the app crashes. This is very simple, a file, a list but you would not believe the problems this has caused us over the years. But I partly blame the developers (Borland), for that.

Sounds like I am saying avoid the SQLite approach, I'm not!! Just trying to offer my experiences.

FWIW, I spend ages adding ID3 stuff to my album mp3's. Vista is quite cool for playing around with that as it displays ID3 stuff as columns in windows explorer. What I also like about Vista is the ability to tag files, usually pictures with some names, e.g. Kids, Home, Friend x, Friend y. It doesn't work as well with music, but, one could tag based on stuff like who owns it (mine or the missus, kids etc), was song released, bpm (dj etc) and probably all kinds of other stuff that people have for their collections. Your SQLite solution could offer the ability to cater for this.

So anyway, we have probably talked this subject too much, I should leave you alone to develop 

Really, the only reason I'd even consider it is because I was fortunate enough to think ahead and perform all database access through a couple of functions... makes it easy to drop in.  But it'd be nice to be able to offer "advanced" users the ability to write filters directly in SQL... then there's no limit to what they can do.

  Being devil's advocate, would offering those users ability to write sql, provide more complex filter arrangements not possibly cause more development than the couple of funtions you have available?

The database is actually very flat now.  Effectively there are only three tables: the master song list, a list of integers of "avalable" songs (this is the list I sort and manipulate), and a list of paths.  CD skins have two more tables: a list of album artists and a list of paths to CD cover art.  All of the data tables such as symbol and color names and values, etc. are hard coded; I used to load them from a datafile but then I ran into problems where someone would update the executable but not the datafile, so I just merged it all in. 

I had kind of worked this out, and for my 2 pennies, it all makes sense based on the problems you needed to overcome and performance you wanted from the solution.

[Chris]

I understand where you are coming from now. I guess the answer to the issue of amount of debugging/development on indexes would come down to the design of the helper functions etc that support functions to get indexes.

I don't have my code here in front of me, but no "fields" are accessed directly.  Everything goes through a function like jb_getsongstring(intSongID,DB_FIELDNAME) or jb_getsongint(intSongID,DB_FIELDNAME).  Really comonly used fields like artist have their own functions like getartist(intSongID), but getartist(intSongID) just calls jb_getsongstring(intSongID, DB_ARTIST).  In the "database", each song is just a bunch of fields in brackets, like this:

Code: [Select]

{145798TAKE}{Take A Chance On Me}{ABBA}{Greatest Hits}{2}{204}{545131}{Pop}{0}
Those are off the top of my head and may not be in the right order but they are File ID, Title, Artist, Album, Track Number, Song Length, File Timestamp, Genre, and Play Count.  So DB_ARTIST evaluates as 3, and so jb_getsongstring loops through 3 sets of brackets and returns whatever is between them.  There are, of course, equivalent putsongstring and putsongint functions.  So to change over to SQL, all I need to do is change jb_getsongstring to

Code: [Select]

sprintf(strQuery, "SELECT %s FROM tblSongs WHERE intSongID = %d", strFieldName(intFieldID),intSongID);
sqlite3_exec(jb_db, strQuery, callback, 0, &zErrMsg);

The callback function appears to actually iterate through the data, so it is slightly more complicated. 

In reality, categories such as decade/genre etc would have permanent indexes that gives benefits of speed of startup (if nothing changed), switching between categories during runtime etc. But a song search etc would probably be a temporary array of song indexes created on the fly. It is probably the performance of the latter that is most important i.e. sql v your own memory based solution.

Right.  And it's unlikely I'll implement a true song search because that gets into the whole "on-screen keyboard" issue, although I could do it I suppose with a dynamic version of the T9w system that's used on phones.  Essentialy, I'd have to figure out how many keys I have available and distribute the alphabet among them, then at startup create matching indexes.  For example, using a 10-key keypad with letters distributed the way they are on a phone, "Take A Chance On Me" comes out to 825322426236663.  So as the user starts typing, all matching songs thus far are displayed; four or five keystrokes should be sufficient to narrow down any song.

None of this is rocket science; filtering, indexes and search are Programming 101. 

in terms of a single scan to check each entry for a match be it on one field match or multiple (effectively a sql query), I would have expected to be fast enough that the delay before results were displayed would not be an issue.

Well, the tricky part here is that I need to be able to do this in a way that doesn't disrupt the play of music or animation on suboptimal hardware, which is why I'd tend toward preindexing everything.  It's spending memory and prep time against run time.  The nice thing is that the database is rarely changed, it's usually just added to, and additions are always at the end of the list.  So I can save the index files after they're created, and just need to insert data into the appropriate indexes when a song is added.  The tricky part there becomes when a song DOES change, I need to extract its data out of the affected indexes and re-add it.  But that's rare.  And there's the big benefit of writing my own indexes and query code; I can optimize for the most usual case.

We use paradox files at work to maintain a list of records in a buffer so we have state if the app crashes. This is very simple, a file, a list but you would not believe the problems this has caused us over the years. But I partly blame the developers (Borland), for that.

Ironically I was just thinking about this last night: storing the jukebox state in a temporary file and offering to restore it on startup.  I already track whether or not shutdown was expected in the log, but dumping the playlist and credit count and offering to reload them would be easy enough.

Sounds like I am saying avoid the SQLite approach, I'm not!! Just trying to offer my experiences.

I'm leaning toward not using it right now. 

So anyway, we have probably talked this subject too much, I should leave you alone to develop 

Not at all, 80% of the features in the jukebox have come from discussions like this.

Being devil's advocate, would offering those users ability to write sql, provide more complex filter arrangements not possibly cause more development than the couple of funtions you have available?

More development?  No, it's simple.  More technical support  Very likely!

--Chris

[ex_directory]

Well, the tricky part here is that I need to be able to do this in a way that doesn't disrupt the play of music or animation on suboptimal hardware, which is why I'd tend toward preindexing everything.  It's spending memory and prep time against run time.

Sorry, your right, I have been thinking recent hardware, multi-threading for so long, I can't remember the last time I saw a real DOS prompt - not that I am really a Windows fan either. What do you believe is your user base now between DOS/Windows? I would imagine your continuing support for cross-OS is affecting design and ability to develop functionality you would like to release?

Ironically I was just thinking about this last night: storing the jukebox state in a temporary file and offering to restore it on startup.  I already track whether or not shutdown was expected in the log, but dumping the playlist and credit count and offering to reload them would be easy enough.

Sounds like you have lots of functionality ideas going on! Guess you would need to continuously keep a log of state, just dumping on shutdown may not be sufficient for power down situations.

[Chris]

What do you believe is your user base now between DOS/Windows? I would imagine your continuing support for cross-OS is affecting design and ability to develop functionality you would like to release?

I actually think my DOS user base is fairly high, because DWJukebox is essentially the ONLY option for a DOS user.  There are a lot of Windows jukes, and let's face it, most of them are better. 

DOS is actually the reason DWJukebox exists, as my first MAME cabinet was DOS-based and putting a jukebox on it was the only way my wife would allow it in the house.  I am actually not a Windows programmer at all; I still code in old-fashioned procedural-style C code.  So I'm really not losing anything.  If a break occurs, it may be because I may try to start using Media Player to play audio rather than the library I'm using, which would give me access to WMA files and remove the patent restrictions that keep me from allowing any kind of commercial use.  The DOS version would still rely on the old library and thus would not inherit the Media Player features.

Ironically I was just thinking about this last night: storing the jukebox state in a temporary file and offering to restore it on startup.  I already track whether or not shutdown was expected in the log, but dumping the playlist and credit count and offering to reload them would be easy enough.

Sounds like you have lots of functionality ideas going on! Guess you would need to continuously keep a log of state, just dumping on shutdown may not be sufficient for power down situations.

Or for serious crash situations that I can't recover from to run the AtExit functions.  But all of the state information would fit in about 2-3K of space and it only needs to be written out when either a song is added to or removed from the queue (by playing or deletion), or a credit is added.

[ex_directory]

I actually think my DOS user base is fairly high, because DWJukebox is essentially the ONLY option for a DOS user.  There are a lot of Windows jukes, and let's face it, most of them are better. 

I think it depends on what you are looking for, I wanted complete customisation, the ability to see album art, and the ability to use joystick controls to access the jukebox functions, apart from the last one not that specific. IMHO, your app is the best for my requirements - and I tried them all!!

DOS is actually the reason DWJukebox exists, as my first MAME cabinet was DOS-based and putting a jukebox on it was the only way my wife would allow it in the house.  I am actually not a Windows programmer at all; I still code in old-fashioned procedural-style C code.  So I'm really not losing anything.  If a break occurs, it may be because I may try to start using Media Player to play audio rather than the library I'm using, which would give me access to WMA files and remove the patent restrictions that keep me from allowing any kind of commercial use.  The DOS version would still rely on the old library and thus would not inherit the Media Player features.

It's a bit of a shame that you are looking at this with possible commercial intentions, personally I feel what the jukebox software badly needs is a good open source solution that can be contributed to by those people that are more interested than just using other people's software. Your product being designed from the customisation point of view would have been a great start. If a community can be built, features get built quicker and well, you know the story - MAME being a great example. There are lots of badly designed jukebox apps out there, fit for the developers purpose maybe but generally not the masses, and 1 year left the developer has moved on to his next project annoyingly 

But no one can knock you for your intentions, it is your baby and your time that has been invested!

[Chris]

It's a bit of a shame that you are looking at this with possible commercial intentions, personally I feel what the jukebox software badly needs is a good open source solution that can be contributed to by those people that are more interested than just using other people's software.

Allowing "commercial use" doesn't mean I intend to sell it.  For example, at least two MAME cabinet manufacturers distribute my software with their cabinets against my requests and wishes.  Those cabinets, although intended for home use, are not being given away for free.  So DWJukebox is part of a commercial product and thus I can be sued by the patent holder of the MP3 patent.  If commercial use could be allowed I wouldn't have to worry about things like this. 

I also had to turn down a potential job for a local bar owner who wanted customized jukeboxes at each booth in his bar.  I've recently had an unwanted job change that cut my salary by 25% per year and my wife and I are struggling to keep our house, so turning down this opportunity was painful.

I intend to keep the basic jukebox itself free, but my financial realities are not going to go away and DWJukebox is my biggest potential asset.  So yes, I am trying to find ways to "monetize" it while keeping it free.  That's why you've seen ads pop up on dwjukebox.com; the $5 per month or so I earn from the clicks will hopefully pay for the site's hosting.  I'm look to possibly start selling things like control kits, keycap labels, bubble tubes, or other accessories that might help people buld a jukebox.  I may even start building jukeboxes and selling them myself, although I would be more likely to do that locally rather than online.  But I still want to give the software itself away.

As far as open source goes: I have released small projects as Open Source before, but as you say this is my baby, and I really don't care to give up control of it just yet.  I spend a great deal of time doing technical support for free as it is; I really can't add time explaining my code to other developers, some of which who will gleefully bash me or question me for decisions I've made and directions I've taken, or code that isn't structured well.  If I were ever to abandon the project, I would probably release the source at that point, but for now I prefer not to.

[ex_directory]

Allowing "commercial use" doesn't mean I intend to sell it.  For example, at least two MAME cabinet manufacturers distribute my software with their cabinets against my requests and wishes.  Those cabinets, although intended for home use, are not being given away for free.  So DWJukebox is part of a commercial product and thus I can be sued by the patent holder of the MP3 patent.  If commercial use could be allowed I wouldn't have to worry about things like this.

Now that is just not cricket. Have you thought of adding a startup splash like in mame where you have to press ok or toggle the joystick. Words to the affect if you are using this software as part of a commercial jukebox this is illegal...?

I intend to keep the basic jukebox itself free, but my financial realities are not going to go away and DWJukebox is my biggest potential asset.  So yes, I am trying to find ways to "monetize" it while keeping it free. 

It's a very difficult one, sounds to me like if you are putting your hopes on this then you need to move the windows version into a position that is marketable for commercial jukeboxes but I guess they also run under dos?

As far as open source goes: I have released small projects as Open Source before, but as you say this is my baby, and I really don't care to give up control of it just yet.  I spend a great deal of time doing technical support for free as it is; I really can't add time explaining my code to other developers, some of which who will gleefully bash me or question me for decisions I've made and directions I've taken, or code that isn't structured well.  If I were ever to abandon the project, I would probably release the source at that point, but for now I prefer not to.

I don't think anyone would disagree with this, now I understand your intentions I think you are doing the right thing.

[Chris]

Now that is just not cricket. Have you thought of adding a startup splash like in mame where you have to press ok or toggle the joystick. Words to the affect if you are using this software as part of a commercial jukebox this is illegal...?

I have, but it would annoy the 99% of users who don't abuse the product.

As far as true commercial use, i.e. putting it in a bar to collect money, I have seriously thought about putting a back door in that would allow anyone who, say, selected a single song 6 times in 10 seconds with no credits in, to pop up an administrative menu that would show version information and allow the user to add credits.  This would make it useless in a true commercial environment.

It's a very difficult one, sounds to me like if you are putting your hopes on this then you need to move the windows version into a position that is marketable for commercial jukeboxes but I guess they also run under dos?

Not really putting any hopes on anything, just trying to get my hobbies to pay for themselves.  And selling controls and decals and such provides a valuable service to jukebox builders as well.  There are already specialized vendors for home arcade products like Ultimarc and GroovyGameGear but no one is doing the same for jukeboxes.  Although GroovyGameGear does have a combined control interface and light controller that is just begging to be the centerpiece of a jukebox control kit.

[ex_directory]

As far as true commercial use, i.e. putting it in a bar to collect money, I have seriously thought about putting a back door in that would allow anyone who, say, selected a single song 6 times in 10 seconds with no credits in, to pop up an administrative menu that would show version information and allow the user to add credits.  This would make it useless in a true commercial environment.

Go for it! I can't imagine any users of this system are going to complain, I can't speak for them (and I am really just a noob here), but I would expect they would support you if it helps your cause and at the end of the day causes no annoyances to them. At the end of the day, I guess a high percentage either have it on free play, have a button for a coin (I do) or if they have a coin door (which they are using it either as a money saving mechanism or the coins are reused).

Not really putting any hopes on anything, just trying to get my hobbies to pay for themselves.  And selling controls and decals and such provides a valuable service to jukebox builders as well.  There are already specialized vendors for home arcade products like Ultimarc and GroovyGameGear but no one is doing the same for jukeboxes.  Although GroovyGameGear does have a combined control interface and light controller that is just begging to be the centerpiece of a jukebox control kit.

Your right, that is missing. On my cab I have replaceable control panels, I remember when my cab was being used more for a jukebox than a games machine that I wanted to build a new CP with red triangular buttons for left, right and nice small white square numbered buttons for song selection (VMJ style), I could not source these. Of course then I was not aware of this forum which would have helped! To start and end my post with the same sentence - Go for it!