If the OS development is slow... make it Open Source!

One interesting comment from the FAQ:

Are the Chameleon development tools open source?

Not for the moment. We give you the details of how to program for the Chameleon, using its operating system and development tools, but we do not give away the source of our own software. Doubtless it could be improved upon in various ways, but one of the things that makes the Chameleon useful is that developers can easily build on the system without worrying about the underlying hardware interface. If there were multiple versions of our tools floating about on the net, we wouldn't be able to make the same promises about stability and compatibility.

Besides this, building the Chameleon and making it useful to developers involved a lot of research, effort, and money.

We could only do this properly if we had a reasonable expectation of earning a living from it, which is why we are not yet ready to give away all our secrets.

http://www.chameleon.synth.net/english/ ... hfaq.shtml

Man, this is very interesting. Thanks a lot for the resource! This gives us some ground... ;=)

This is why computers don't quite have the killer accuracy of the MPCs. However, they do use linux and even windows in phones (and other common devices). Mine has crashed a few times, how lame. This is exactly why it doesn't belong on dedicated hardware like the MPC (phones aren't dedicated to making calls anymore).

Linux and Windows variants are sometimes used to run the USER INTERFACE of the phone -- like PalmOS or whatever. This is running on a separate processor from the DSP that is handling the communication. Linux does not run as an RTOS in the data plane (low-level communication) of any communication device that I know of. It runs in the control plane of some, and at the user interface level of quite a few.

I know the above sounds very pedantic and I don't mean it that way; I'm just trying to put what I think are some basic facts in front of the folks who are thinking about undertaking this. If you use Linux in real-time mode for this task, you will be putting a lot of resource pressure on yourself from the get-go. Keep this in mind: the CPU in the MPC is not vastly overpowered for what it does, in spite of what has been speculated casually around here. No one pays for a CPU that is an order of magnitude more powerful than they need in a consumer product. So you can be sure that it won't be a slam-dunk to achieve the bandwidths and latencies that you need to to make this thing work up to snuff.

<It's hard for me to imagine we're even having this conversation. It's like deciding you're going to rip out the software in your cell phone and replace it with new software written from scratch because there is a bug in some app. haha.>

-illiac

An interesting letter from a guy at Linux Audio Development mailing list

--

I have done some development with RTLinux, a hard-realtime Linux
solution, and it is a bit of a pain-in-the-ass to program for, since
you are working in kernel-space and anything wrong you do will crash
the whole computer. however, there is a way of using gdb with it, to
catch errors before they cause a system crash. this makes things a
little easier. and the fact is you can get VERY low latency using it.

However, the project for which I was using it migrated our drivers to
Linux 2.6, and when we did so, we found that we were able to get very
very good timing out of it. This is because 2.6 incorporated the
"preemptive" kernel locks, and when compiled with an HZ value of 1000
(that is, the basic OS interval timer for task switching), we were
able to write code in user mode which had latency of less than 1ms.
(This is including some I/O with a PCI board -- a data acquisition
card to be precise.)

So I would recommend not worrying too much about using a hard realtime
system -- these days "soft" realtime seems to be rather good for most
purposes.

(The difference is that in soft realtime, you have no *guarantee* of
the timing. Something could happen in an unrelated part of the OS that
causes your process to wait longer than usual, and you could miss
something. However, in practise I've found that running under a
properly configured 2.6 kernel, this is rare enough that it's not
really worth worrying about!)

In this particular case, something to watch out for is whether there
is an MMU. I think likely there is not. (Haven't check the linked
docs) You'll probably have to run Linux sans-MMU, meaning that
processes can step on each other if you're not careful! However, it's
not *that* big a problem. Just makes development slightly more
annoying. I don't have any information on latency reports for
MMU-less Linux.


Steve

--

On Thu, Jul 27, 2006 at 08:46:27PM +0200, Jay Vaughan wrote:

>>>> > > > > There are public-domain RTOSes available that are suitable for this
>>>> > > > > task. To those, you can add drivers for USB and FAT32. Without an
>>>> > > > > RTOS to give you hard real-time scheduling, you have no chance to
>>>> > > > > achieve the rock-steady timing that the MPC currently has.
>> > >that sucks. that really does. because my linux systems have the same
>> > >rock steady timing as the MPC. actually, their timing is even better
>> > >than the MPC. somebody must have made a mistake around here.
> >
> > i assure you, linux performs on par with "other public-domain RTOSes"
> > in the real-time department, in the right hands .. like all good
> > instruments ..

Let me add one more voice. At my (current) work we develop space
telecom equipment, all of it these days consisting of one or more
dedicated interface cards plugged into a Linux PC. All processing
is done in software. Sample frequencies are up to a few MHz, and
latency requirements more demanding than for any audio work.

Five years ago we used RTAI for the critical work. It was a lot
of pain. Since then everything runs on standard Linux kernels
optimised a bit for real-time. These days that means it's just
a stock 2.6 kernel compiled with the right configuration.

-- FA Lascia la spina, cogli la rosa.

Look, I think that we should stick to our first option, which is develop the proposal.

I know, this discussion would take place if Akai rejected us and refused to help in any way definitely. Then, I would continue to pursue the development of an OS from scratch.

But, for the time, let's just stick to the Proposal and what could we do to convince akai. If anyone here can contribute arguments and stuff, please do.

Let me add one more voice. At my (current) work we develop space
telecom equipment, all of it these days consisting of one or more
dedicated interface cards plugged into a Linux PC. All processing
is done in software. Sample frequencies are up to a few MHz, and
latency requirements more demanding than for any audio work.

Five years ago we used RTAI for the critical work. It was a lot
of pain. Since then everything runs on standard Linux kernels
optimised a bit for real-time. These days that means it's just
a stock 2.6 kernel compiled with the right configuration.

But, the MPC4000 is not a modern PC! It was not even a modern PC when it was released 4 years ago.

we were
able to write code in user mode which had latency of less than 1ms.

I.e., 48 sample periods at 48KHz, or one MIDI tick at 960ppq @ 60bpm.
The MPC4000 has 64- or 128-note polyphony, something like that.

You know, it is still, today, no slam dunk to run 64 tracks of 24-bit audio on a PC with low latency. Thinking that this is an easy thing on the the MPC, and that there's enough slop to afford to run Linux, ... All I can say is that there needs to be some really careful checking of resource constraints before going far down this path.

-illiac

Kalei wrote:
Not really. Akai could have reached the same results as they have with current OS WAY faster than they did. On more than 1 occasion it took them over 8 (!) months to come with an update for the 4000. I am sure that if Akai would have spent their time working on the 4000 they could have managed all the updates they've done for it within 6 months after its release, or even less.

Kalei wrote:
Did you even READ what I wrote?

Yes. You were just speculating what they can/couldn't do. As I speculate..maybe it wasn't/isn't high a priority or they felt that it is solid enough for music production. But since you are giving your expert opinion, I will take you word for it. Yes, Akai could have managed all the updates and have it completed in 6 months IF they would have spent time working on it.

.........name one product/software that is as powerful as an MPC 4000 and works flawlessly I will help you out...none

I can tell you that there is NO WAY Akai will open source the MPC.
That would be technical suicide.
Any other manufacturer would be able to have their sequencer and DSP for free.
Ask Roland to open source COSM or RDAC. It won't happen.
You are dreaming to think it will.

The only way to do it would be to do your own OS and that would be a seriously big undertaking and not worth the effort or cost tothe person doing it.

Try pulling together some money and ask if a group of you can pay the engineering costs for Akai to some updates, that would be the best bet.

If the features added were good enough, I'd pay a $100 bucks. If it's bug fixes, I don't care because my system works fine for me.

jahrome wrote:...blablabla...

Im not gonna reply to you anymore cause I dont want you to ruin another good thread. So take your best shot and have fun with it. Go away troll.

Lumpy wrote:I can tell you that there is NO WAY Akai will open source the MPC.

Im afraid your right about this

Kalei wrote:
Im not gonna reply to you anymore cause I dont want you to ruin another good thread. So take your best shot and have fun with it.

Another good thread?? About what? Something that will never happen. I was taking shots at you. Just pointing out that there is much more to it than your claim that they can fix the OS in 6 months if they wanted. There is a billion dollar business whose software/OS you use everyday that has all sorts of bugs Akai is not a billion dollar business...

i dont think xp has that much bugs to be honest... its the software you install with xp that has the bugs (vsts, cubase, hw divers etc)

Kalei wrote:

Lumpy wrote:I can tell you that there is NO WAY Akai will open source the MPC.

Im afraid your right about this

Er guys,
can we at least ASK them first??

McSmooth wrote:

alpha80 wrote:....on another note, anyone here familiar with how flash rom works?

for instance, on the 2KXL, you can upgrade/replace your flash ROM up to 8 MB.

I have no idea if ours is on the main board, or seperate, but either way, there's got to be some alternate routing capabilities....

That has nothing to do with this topic. The 2k's flash rom was just a way to store samples when the power was off. This is similarly to a flash card except it was fast enough to be used directly off the ROM instead of having to load it into RAM like would normally.

My bad, I thaught it was relvant, cause I heard the #1 reason why the 4000's OS updates are a nightmare to develop, is due to it's limited (2MB ) Flash ROM....

I'm not too technologically saavy, so apologies if the idea of expanding the limited Flash ROM is complete lunacy.

Peace. Good luck to anyone who attempts this sh!t.

This means you, JJ

drumtrack wrote:
i dont think xp has that much bugs to be honest... its the software you install with xp that has the bugs (vsts, cubase, hw divers etc)

It doesn't matter that you think it doesn't have 'that much bugs'. It does have bugs. It will never be bug free. The same goes for those other programs.