PlayIt open source?
jim lesurf (2082) 1438 posts |
I’ve exchanged some emails with Chris Martin about various aspects of audio on the newer hardware, etc. One specific issue has cropped up where some advice would be welcome. Chris is thinking of releasing the source code for PlayIt as open source for further development. This would eventually facilitate improvements like allowing for 24 bit samples or USB. However AIUI PlayIt relies on sources in BASIC bytecode. His concern is that this makes it awkward for using a system like CVS. Wants to avoid the risk that text versions of the sources end up differing from the bytecode which gets used to create the actual PlayIt module. OK, I don’t fully understand this, but I’m raising it to invite advice/comments that may aid PlayIt becoming open source and thus more easily developed as the audio scene changes. Jim |
Rick Murray (539) 13851 posts |
Do you just mean “tokenised BASIC”?
Can he use BASIC-as-text files, or does any part of the code rely upon line numbering? If not, try Yup. Just tried it with a dummy file. Works fine. BASIC is happy to load text and tokenise it on the fly. If the PlayIt build process can be tweaked to do that, then it will hopefully be more CVS friendly.
All in all, this would be a good thing. PlayIt being open source, a modification to allow it to fully exercise the functionalities provided by Dave’s USB driver, can you see where this line of thought might be going? :-) |
jim lesurf (2082) 1438 posts |
I think so, but am not sure. I’m trying to describe a problem I don’t understand, and I’ve not seen the source code, etc.
Can’t try that as I don’t have the sources myself. I am not sure but I think the problem is that the process generates the PlayIt module by ‘translating’ the BASIC tokens into assembler in some way. But if so, I don’t know how. In the end I guess the best thing is to see if I can ask Chris to make the files available so others who know far more about programming than myself can have a look.
Yes, that’s my view. Having a version that can use the new USB modules is one thing I have in mind as a potentially very useful possibility. Another is the need to cope with 24bit. These days the use of 24bit files is increasing, and new machines like the PandaBoards have 24 bit hardware. The problem at present is that: We can’t even handle 24bit audio with any of the established players (Colin and Dave’s new USB modules being the newly-arriving exceptions.) It would be a step forward to have a player like !PlaySound/PlayIt that can accepts 24bit file input – even if it had to trunkate to 16bit for now to send via SharedSound/SoundDMA for the internal hardware. And once we had that, given the hardware abilities, it would encourage people to change SharedSound/SoundDMA to also handle 24bit to make better use of hardware. But as a step 1, just being able to play 96k/24 files, even if what gets to hardware is 96k/16 would be a very useful advance. Better than simply not being able to play 96k/24 using apps like !PlaySound and !DigitalCD at all. Jim |
Trevor Johnson (329) 1645 posts |
Do you just mean “tokenised BASIC”?I think so, but am not sure. If Chris fancies signing up himself (assuming he’s not already done so) then it may be simpler coming from the horse’s mouth. |
jim lesurf (2082) 1438 posts |
Agreed. I’ve suggested that to him. Hope he’ll join in! Jim |
David Pitt (102) 743 posts |
There is PlayIt 1.73r2 source code on Chris’s site http://www.users.on.net/~belles/software/playit/ |
jim lesurf (2082) 1438 posts |
Yes, although note that at present Chris expects people to contact him if they want to make developments/changes to ensure we avoid problems with consistency, etc. IIUC He’s more recently been thinking it should just be open source in a more conventional way a’la CVS but remains concerned about various aspects of this. Hopefully he’ll join the forum sometime and will then explain, correcting any of my muddles. Jim |
Steve Fryatt (216) 2105 posts |
Wants to avoid the risk that text versions of the sources end up differing from the bytecode which gets used to create the actual PlayIt module. A very quick look suggests that the source is a set of BASIC Assembler files: Chris is correct that this won’t work well in a source control system. The solution that I used for my own BASIC Assember sources (which also relied on ExtBasASM, adding extra maintainability fun) was to convert the code into ObjASM/AsASM format. This is plain text, so systems like CVS and SVN handle it fine. It’s also much more portable, and can be built on other systems (I now assemble all of my modules using the GCCSDK on Linux, allowing access to all the same build tools that I use for C). Obviously there’s some conversion work required. I think it was taking me about a day to do one of my module’s sources by the end, although clearly size and familiarality will play a part. In hindsight, I think it was definitely time well spent. Clearly the amount of work for PlayIt will depend on how much “clever” use the sources make of BASIC. A couple of my modules required a bit of thought, and IIRC one even required a small C “helper” utility to be written. |
jim lesurf (2082) 1438 posts |
The key question is: Anyone willing and able to do this for the PlayIt sources? I’d love to do it. But it is way beyond my abilities. Stopped using BASIC for anything much many years ago. And I’ve hardly ever used assembler beyond typing in things produced by others back in the ‘Yellow Pages’ days. :-/ Jim |
Steve Fryatt (216) 2105 posts |
Potentially, if Chris (and any other maintainers) is happy with the idea. I wouldn’t like to put a timescale on doing it, though. |
jim lesurf (2082) 1438 posts |
I’ve emailed Chris to see what he thinks of this. If anyone else is interested in having a go on a shorter timescale, please speak up. :-) Jim |
Theo Markettos (89) 919 posts |
BASIC is quite happy loading un-tokenised programs written as text. So it’s quite feasible to check TEXTSAVEd BASIC into CVS (or whatever) and then, as long as they’re filetyped as text, they’ll run just fine as a normal BASIC program. Here’s an example. You just have to remember to edit them in something that won’t re-tokenise them – Zap’s BasTxt mode is good for this. |
jim lesurf (2082) 1438 posts |
I’ve suggested to Chris that he reads this thread. Hopefully he can then comment on things like the above. But if I don’t hear from him wrt the email I sent recently I’ll pass the info on. If possible, though, I want to cut myself out of that loop because I’m concerned I’ll misreport due to my not fully understanding! Jim |
Kim Faulkner (84) 30 posts |
I’ve just seen this thread from several months ago and was wondering whether there has been any more recent progress on this topic. Kim |
Rick Murray (539) 13851 posts |
MelIDI as well. Any news? |
Fred Graute (114) 645 posts |
The question is does it support the LIBRARY command in such a case. I’m using BASICtxt files for StrongED’s source but found that I couldn’t use LIBRARY, the files had to be converted to tokenised BASIC first. I’ve converted the PlayIt source so it builds using the same technique that I use for StrongED. A copy can be found here If anyone thinks this is useful then feel free to use it. |
jim lesurf (2082) 1438 posts |
FWIW I’ve not been in contact with Chris for some time and I know he became ‘otherwise occupied’ with a day job. However I’d really welcome a version of the PlayIt module that could make full use of USB Audio and output the higher quality material that way. Alas, I’m clueless about modules and assembler, and not much grasp now of BASIC, either, so all I can do is hope/encourage! Jim |