multi cd ripper machine

[willyhoops]

any idea what it would take to get dbpoweramp to work with one of these?

http://www.mfdigital.com/baxter.html

[LtData]

Re: multi cd ripper machine

It depends on how the computer recognizes it. If it is just treated as an external CD drive, you should be able to use it with dMC. However, how the automation aspect of it works is beyond me.

[Spoon]

Re: multi cd ripper machine

We are about (this week or next) to start developing for robotic arms, as they say, watch this space.

[bhoar]

Re: multi cd ripper machine

any idea what it would take to get dbpoweramp to work with one of these?

http://www.mfdigital.com/baxter.html

The baxter device is pretty simple:

1. A PATA CD/DVD drive.
2. A circuit board containing: a) a 2-port USB 2.0 hub b) a USB 2.0<->PATA bridge chipset hanging off of the hub and c) a connection to the robot also hanging off of the hub.
3. The robot, which contains the control circuitry in the arm "tower". I can't recall if the board in #2 above includes a USB-to-TTL (or USB-to-serial) board chip, or if the robot board in the tower includes a low-speed USB interface. Too worried about shorting out a unit to poke any further.

The USB driver itself is simply microsoft's bulk USB demo driver, renamed or recompiled, and associated with the vendor/device #s of the robot device. The protocol must be pretty simple, but you don't want to deal with this sort of thing at the USB level for several reasons. So, use the SDK, available from MFD, instead.

And the Baxter SDK is also pretty simple. A year or so ago I wrote two CLI utilities, one of which sends SDK commands and the other one monitors the tray status (using the Mechanism Status CDB which works with contemporary drives). I then wrote a batch file that calls the former to cycle a disc (remove, insert) every time the latter program indicates the drive has been opened and then closes the drive after the robot is done.

Unfortunately, the unit doesn't handle receiving a lot of INIT commands in one session, so I should have moved from a self-contained CLI utility to an architecture that keeps a process running after the initial INIT with a CLI that tells the existing process to send the commands. But by then I'd moved onto messing with bigger robots.

Anyway, the above approach works pretty well with any program that auto-ejects when done and auto-detects inserted discs, primarily because it doesn't have to interact with them at all.

The robot portion of the SDK has ~eight or nine simple calls, and their optical drive library is about the same (but I never used the latter).

Spoon will probably hate me for this, but: I suspect that spoon could include simple support for this device (and a very basic config UI) with less than a day's worth of coding. Perhaps after he gets a look at the Baxter SDK docs, assuming they having grown substantially in the last year and half, he won't be so mad at me.

Testing/certification (e.g. are the USB bridge and drive well behaved and if not, is there a coding workaround) would take more time, of course.

Convincing the manufacturer that sending a free unit would be in their best interests could also be fun.

-brendan

[willyhoops]

Re: multi cd ripper machine

spoon.... can i control dbpoweramp using com or something until such time as you have the robotic arm sorftware working?

i really want of these babies to put to rest forever my rippping hassles. and then i can rip all my friends cds in a few days and build a gigantic collection.

i will pay you $100 if you add support for it soon! not much for a days work but my contribution!

[Spoon]

Re: multi cd ripper machine

I am afraid to make cd ripper a COM object would take the best part of 2 weeks, I am not sure we are going to go that way.

[SoundOfMind]

Re: multi cd ripper machine

Creating a COM interface for the ripper would open up many possibilities. One of the nicest aspects is that you can contain your multithreaded tasks in the server, making your GUI a much simpler single threaded program. The server is assigned a task. It reports progress and errors back to the GUI. The GUI is just there to interact with the user. Separating in this manner is a great way to divide and conquer.

Various modules could be implemented as separate servers, so the user would have only what they need. These modules could be licensed individually.

The robotic ripper server could have plugins for various makes and models of robotic burners, exposing a uniform interface for the GUI, as they all have similar functionality. Wouldn't it be fun to operate a multiple burner system?

[petriburg]

Re: multi cd ripper machine

Shouldn't this be a topic for the "Wishlist" facility?