We have been in touch and some support has been offered.

:)

@Joeled

Aside from permission to repackage other peoples software, please be sure that your "install script" does version checking on EVERYTHING.

Releasing a installer that might revert future versions of programs or libraries would NOT be a helpful thing for a newcomer.

:)

@kas1e

If somebody wanted to add CAMD support, I can provide a small example program that shows exactly what is needed (and it's not much).

It's all even easier now that camd is pre-installed in the OS and the SDK.

Code is available to anyone who asks for it.

:)

Actually, it's even small enough that I could cut & Paste it right in to this post, but I don't want to spam the thread with code.

M-Audio makes a lot of MIDI devices.
I recently found they are rearranging their website information pages to give better information on exactly which devices are "class compatible".

I have tested a few of these myself, but I trust that all these can be assumerd to work with the camd usb driver.

All are M-Audio brand:

Axiom 25, 49, 61
Axiom 25, 49, 61 (2nd gen)
Axiom Pro 25, 49, 61
eKeys 37
Keystation Mini 32
Keystation 49e, 61es, 88es
KeyStudio 25, 49
KeyRig 25, 49
Oxygen 8v2, 49, 61 (silver)
Oxygen 25/49/61/88 (blue)
O2
MidAir
MidAir 25/37
MIDISport Uno (current model)
MIDISport 1x1 (black top)
MIDISport 2x2 & 4x4 Anniversary Edition
ProKeys 88, 88sx
UC-33e
X-Session Pro
X-Session UC-17

The website even gives details about identifying models that MIGHT be compatible, like the Uno (I have an old one that does not work) and the 1X1, which I have a "black top" model that works great.

Also, on their Keyboards and controllers that support USB and MIDI, there is usually an option to use the device MIDI connections as aditional MIDI ports for CAMD, so you get a device AND an few more MIDI ports for CAMD, all in one!

Speaking as a developer, I am frustrated with the "vocal few" that seek to piss on anything good that is not for their brand of Amiga. Instead of building for their own platform, they seek to spoil what others build. I could go into more detail, but I see no benefit.

I just try to remember that most of our community, and surely the best of our community, are just out there USING the platform instead of complaining about what they don't have.

Speaking as a user, I am amazed at what we have already. I have owned classics, a micro, and now an X1000. I am using a powerful, stable Amiga that uses standard mouse, keyboard, monitor, RAM, sound and networking hardware. I am running a graphics card that is WAY more powerful than OCS or ECS could ever touch. And AmigaOS has elevated my expectations too. If I were to sit in front of Workbench 3.0 right now I would be sorely disappointed. It's just not as powerful or graceful as what we have today.

Please think about that for a moment. What is 4.x "worth" over the previous classic versions? Speaking for myself, the hundreds of hours spent using this OS compared to the money paid for it. (for me, it's thousands of hours easily)

I am grateful that the programmers leading the way are planning for the future. I assume they know better than I do what should happen next, and I am NOT here to tell them what to do or how to do it.

I am glad that development continues, and I'll contribute whatever I can towards that goal.

Meanwhile I'm learning to just ignore those who seek to spoil the party for the rest of us.

And a big "Thank You" for those getting it done.

The CDIn header in the X1000, like all inputs, are for recording only. There is no path inside the chip for monitoring inputs directly.
I understand this is also true for at least SOME versions of ENVY24HT.

Since HDAudio is the new standard designed to replace AC-97, it is likely that this will also be the case with most newer audio chips as they are released.

I am currently working on a software solution.

LyleHaze

@ChrisH

Most of the previous drivers would not compile on my standard SDK installation. Because of this I assumed that they were cross-compiled from another system.

I later found out that they HAD been compiled natively, but they required some compiler tools and configuration files that I am not familiar with. There was also at least one tool that was missing completely. We had no way to generate modefiles, and no documentation on how they are formatted. One of the things I did accomplish was to write an audio modefile generator that works from a (very) simple text source file to generate Modefiles. The programmer just describes the desired modefile contents and lets the tool create the modefile as part of "make".

Creating newer drivers might benefit, because "hdaudio" is the new standard, intended to replace AC97. One of the design goals was to make all hdaudio chips compatible with a single driver. I will NOT claim that this driver is universally compatible (I had enough of a challenge getting it to work right on ONE!) But it should provide a good starting point for other hdaudio chips to come.

Once I realized that hdaudio was really a "common interface", I found and studied the official intel "master document" for HDAudio, which went a long way towards filling in some missing details from the datasheet for the 92HD700 chip we are using.

Thanks, but in truth I am just the last runner in the relay race.
Davy, AlexC, and Rene did the biggest part of the driver.

It is good to have it working though.

My wife says all future projects will be limited to eight hours daily.
It think she missed me.

Now in progress.

"touch" is a command to change the "last edited" date of the specified files to NOW.

It is especially useful to developers to force make to recompile a file.

But all I know about "Sid" is that he is the Science Kid. :)

"can anyone tell me what kind of CPU socket XENA features?"

Xena is not socketed. She is soldered directly to the Nemo board.
She has no heatsink, no fan, and no need for either of them.
Access to her available pins are through the Xorro slot, using a
board available from AmigaKit.

The primary processor on the Nemo board is a PA6-T.
It is not in a socket. This will make choosing a fan based on
the socket used a bit tricky, at least.

I don't think it's necessary (or wise) to UnLock a lock that you never Lock'ed successfully.

I was going to say that you cannot get a shared lock if there is already an exclusive lock.. the docs says that only files will get exclusive locks though. :)

I can now provide a bit more information.

If you need gameport MIDI right now, you can
roll back the dos_lib to 53.115 or earlier.

It looks like that update prevents any CAMD drivers from
even attempting to load.

The issue is in camd.library, and has been corrected.
version 53.3 is in the pipeline, and will be released
by the usual channels after suitable testing.

Again, thanks everyone for your cooperation.

Lyle

[edit] more accurate version info, noted as repair in progress.

My micro is now at update5, and the gameport MIDI is still there.

I'll be out running errands with my lovely wife, and will add more updates later.

Lyle

Good Morning!
When I stay up all night coding, I miss these early morning posts.

I had two reports of CAMD failure on the Envy24HT driver. This is the first report I have heard from a different driver.

I still have a VIA686 sound card driver on my Micro.. and it has not been updated in AGES.. Maybe I can do gradual updates and see where we lost CAMD at.

I will try to get this in the next few days.

Also, as Raziel noted, USB midi ports still work. and if you are interested in performance, they work much better than sound card MIDI ports.

I'll reply back here once I know more about the problem.

Thanks for the bug report!

Lyle

I don't post facebook links, but please search Facebook for "A-EON Technology".
In addition to new news, he also has regular posts about the history of Amigas.

[edit] "Technology" is correct, "Technologies" was incorrect.
There can be only one Trevor.

If you have access to a windows machine, search for HPUSBFW.EXE
It has "repaired" every trashed thumb drive I have had so far.

Warning: The contents of the drive will be lost.

p.s. That's a web search, as in googley or something.

I would assume that being tolerant of vibration would be done with buffering.. if the buffer is long enough to keep data flowing while the laser gets "back on track".. then you're in luck!

Graffias79,
If it said "Recording.." then it IS a class compatible device.
The problem is probably due to the "limited" support we have right now for Audio transfers on the USB bus.

Please allow me to explain:
The current USB stack has three different internal "handlers", which are selected depending on whether the device is USB1 or USB2, and also depending on what kind of USB chipset you have, and possibly what kind of Hub you are using. (it's a bit of a riddle to me)

So, the three current options are "OHCI", "EHCI", and "UHCI". I'm pretty sure I got them in the wrong order. At this time, only one of the three supports Isochronous transfers, which are required for Audio work. (you might recall from our previous discussion)

So, depending on what you plug in, and what you plug it into, we may or may not be able to transfer audio data. This sounds like the most likely cause for your zero file length problem.

So far, we know that the built-in ports on an X1000 WILL work. we know that the built-in ports on a SAM-Flex WILL work, and we know that the builtin ports on an XE WILL NOT work. But it also might have something to do with whether your device is 1.0, 1.1 or 2.0.. We don't yet have all the details.
A PCI card with a NEC chipset should also work.

I must be clear.. the "limited" support for ISO transfers was pretty much untested until a few weeks ago. Now that this tool is available for testing, we MIGHT get more support for ISO transfers in the future, But right now our USB team is busy working on USB3 (XHCI), and that is WAY more important!

So, your device IS class compatible, and given what I described here it may be supported in the future, but not at this time.

Thanks for testing!

broadblues:
There are two common brands: PL2303 and FTDI.
The PL2303 has been cloned a lot, and often does not quite comply with it's own definitions.. so it would be a poor choice as you can never tell if it's a "real" chip.
The FTDI chips are much better protected, piracy wise.
After a long series of letter writing and NDA signing, I did finally get the developers information. It's just another project that I'll get around to "someday".
Too bad about the NDA, or I could release the documents to someone with more time on their hands.
I was excited about it, but then, how many people nowadays really need more serial ports?