ChipdiscoDJ v0.21 public release (Page 7 of 7)

having same problem as the others with adding files.  tried add mod,add playlist and drag/drop.  win xp sp3, java (build 1.7.0-b147)

shiroshii - I'd like to support .it, but I'd have to get considerably better at coding in order to implement the filters. The NNAs, I *think* I could get my head around, but I'll have to research the format. I'd also love to support AHX, but that's a whole different kettle of fish...

Everything fine for me on Win 7 64bits, you're the man Syphus !

Oh dear! Could you try running it from a shell window as described above to see if it puts out an error message? If it's starting up and then just going nuts, it should be printing a stack trace with details of the exception and that might hold some helpful clues. Thanks!

Sorry for the delay in replying - the site normally emails me when a thread I'm subscribed to gets a reply, but this time it didn't... Thanks for the log - the first exception is expected, just means the config files aren't in place (but they're not necessary so that's cool). So yeah, Pulse. I've been reading up on this for the RaspberryPi stuff I'm doing with a heavily cut-down version of Chipdisco. Seems that the Pulse situation is fairly crazy in Debian at the minute, particularly on ARM (although I assume you're on x86/x64), and the only thing I can think of to suggest is that you experiment with uninstalling and reinstalling ALSA, Pulse and the associated bits and pieces in different combinations. It's annoying that Linux audio always causes such problems with Oracle's JVM, especially since it *should* be better in terms of latency and performance than Windows' or OS X's interfaces to the JVM. Someone's introduced me to a project called 'jjack' (yup, Java JACK) and though it'll mean forking my code and probably a fair bit of redevelopment, I'm hoping that it'll behave like a native library that'll speak to ALSA/Pulse in a much more friendly and compatible way.

Actually, I think even if you recompiled the whole thing on your system, you'd get the same errors: these errors are the stack traces I've told Chipdisco to print in the event of the types of problems it's running into, so technically it's working just as it should. Hopefully a bit of ALSA/Pulse tweaking (though not to the extent that it risks ruining your system) will help...

Oh, as for the sluggishness, I'm not sure what's happening there. Is there any chance you're using the open-JDK? Oracle's JVM doesn't come as standard since there are licencing issues at odds with Debian and most other Linux distros. (Apologies if we've been through this before, by the way - it's late and I can't remember!) Open-JDK apparently has a range of problems of its own, some concerning sound, some concerning JIT runtime compilation stuff that I don't understand. Also, my brain's starting to blur the boundaries between the x86 and the ARM issues, some of which are distinct and some of which are shared... I'm not sure how to do it on x86 Linux, but I think you can download a full JVM package from Oracle's website (maybe ~30MB), unpack it and then temporarily point your global java path vars at it. You'd best search for a tutorial for that, though, written by somebody who's actually (and safely) done it

Hi SketchMan3! I'm afraid there are various tedious reasons why Chipdisco isn't resizeable, the most stark and unilluminating of which is that Processing/Java applications don't resize well. It's possible to resize them, but because so many percentage and coordinate-based layout values rely on fixed dimensions and can't be specified as variables during the initial setup/loading, resizing causes everything to break. I spent a lot of time trying to work around this and did actually figure out how the problem could mostly be solved, but it required a few too many compromises and a lot more work than I could afford to put into it (especially after we moved house and had a baby).

In parallel with all this, I was getting annoyed by the fiddliness of the 800x600 interface Chipdisco originally used (I'd wanted to use it on my netbooks) and I just decided that, for the sake of being able to use Chipdisco comfortably the way I was trying to use it - in dark nightclubs after a few drinks - I would increase the size and make all those control elements huge and foolproof. No more pixel-sniping in the dark with a crappy netbook touchpad! The downside is that it forces me to take a 12" Macbook or a 14" VAIO out to gigs, but then my Eee 901 netbook had been struggling with playback occasionally and I'd been starting to doubt that this was a netbook-friendly app. Java's just a resource-hog anyway, especially with my inefficient code, but it's the only language I know

Readme/config files in zips: good question! Easy answer, too: the last time I fixed and rebuilt all the zips, I forgot to manually add them. When I get a spare moment, I'll add them into the build process so it's done automatically

Sorry about the resize thing. I know it's obnoxious of a program to refuse to resize gracefully and one day I'll crack the problem entirely, so it can be done freely (or proportionally). It's a problem for Processing in general, so I occasionally ask around in the Processing community to see if progress has been made. Some day...