A plan for using a Palm PDA as a display for a MidiBox

[fluke]

Like many people on this forum, i would like to use my Palm PDA as a display for a MidiBox.  I have a plan for how to do this.  However,  i also have a 6 week old son, so i don't have time to build a MidiBox at the moment.  I will probably have time to write the Palm software side.

My plan isto take the PalmOrb software and replace the commands with ones that take full advantage of the screen.  The Palm would be linked to the Midibox Core via an IIC_MIDI interface speaking RS-232 at 38400 baud instead of MIDI. Newer Palms without a serial port could be connected via IR.

The command set would include characters at 3x6, 5x8 and 10x16 sizes, line, box, filled rectangle and bitmap drawing.  Some extra custom functions could be developed for drawing such things as ADSR envelopes.

So if someone has time now to build the hardware and write the software for the Core module, let me know and i'll start on the Palm software.

[DrBunsen]

linked to the Midibox Core via an IIC_MIDI interface speaking RS-232 at 38400 baud instead of MIDI. ...

So if someone has time now to build the hardware ...

Wouldn't the MBHP LTC module do for this?

It's a nice plan :)  I can see how taking advantage of the full screen would be good.  I'm assuming by using the PalmOrb code as a starting point, the Palm would still be emulating an MO display, but with an arbitrary size to use the full screen width and height.  Or is this more of a jumping off point, and you plan to create a custom Palm serial LCD software controller? 

Any thoughts on emulating any of the other existing LCD types, like HD44780?

Using the touchscreen or buttons on the Palm to emulate MIDIbox button presses would be somewhat cool too.

[DrBunsen]

There might also be something useful in TK's MIOS TV project

Btw.: the next MIOS version will support a new display type #6 which redirects all print commands directly to the MIDI Out based on the new MBHP_TV protocol. By changing the device ID up to 128 "MLCDs" can be addressed in this way - not only the MBHP_TV itself, but also other "slaves" which support this protocol (example driver for a character LCD as slave will follow).

I also plan to include a "soft font" feature into the MBHP_TV which allows to create special characters dynamically like known from character LCDs - hold the line ;-)

[DrBunsen]

Custom LCD driver

Since MIOS V1.3 it is possible to integrate a custom LCD driver into the application. This allows programmers to write low-level drivers not only for GLCDs, but also for IIC or LED digit displays, without "touching" the operating system. And they are able to use the same MIOS_LCD_* functions like for other displays.

[fluke]

I am planning on a completely custom protocol.  PalmOrb already emulates a 20x4 Maxtrix Orbital, which is a HD44780 accessed via serial, so i wanted to do something more, a bitmap display rather a purely character based one.  I was thinking of using MIOS's custom LCD driver functionallity and upgrading the applications to take full advantage of the Palm. (Not that i have time to do that at the moment.)

The MBHP LTC would work if the display was accessed over MIDI, but wouldn't that mean you'd loose access to the MIDI out port of the Core?

[DrBunsen]

Sorry if I'm pointing out things you've already discovered.  You're the first of us to put up a coherent plan to bring this off.

The MBHP LTC would work if the display was accessed over MIDI

Well, there's a serial COM port on it as well, but you may be right about IIC straight to RS-232 or IR being a better bet.  My last quote seems to indicate so.  And it seems you wouldn't have to update the OS/apps, just build a new LCD definition.

but wouldn't that mean you'd loose access to the MIDI out port of the Core?

Not sure.  I'll read some more.

[stryd_one]

Not sure.  I'll read some more.

IIC_MIDI anyone? :)

[DrBunsen]

but wouldn't that mean you'd loose access to the MIDI out port of the Core?

Nope, in the first lines of the MBHP_LTC page it says it's a second MIDI out, a MIDI through, and a COM port.

But as the custom LCD definition from the MBPH_LCD page says it already provides for IIC displays, converting that to RS-232 might be simpler.  I dunno, last time I went looking for IIC to RS232 stuff I couldn't find a chip for it, just expensive diagnostic handsets.  But perhaps the Google gods were not with me that day.

Today they seem a little kinder

[tos]

Errrr, why not write a simple PDA app that holds all of the bitmaps or at least optimizes the drawing so you don't have to send(and store on PIC) whole image via serial?

[DrBunsen]

I don't -think- fluke is planning to write a framebuffer in the PIC  ???

This page mentions a part - P87LPC760 - 14 pins I2C and UART.  It's on the Phillips Semiconductor forums, so I'd guess it's a phillips part.

[fluke]

Here's a screenshot to illustrate what sort of commands i'm planning to implement:

While you could use it as a framebuffer, i'd expect most of the commands to be text drawing, with the occasional line or box.

The P87LPC760 is 8051-based microcontroller.  PICs are nicer to use and we already have the IIC_MIDI and IIC_SPEAKJET projects to base it on.

[tos]

nifty....but i have bigger plans(that probbably aren't gonna see the daylight bkz of the amount of work that I have). Anyway, look at the Pioneer DJM-909 to get the idea.

[stryd_one]

Just my 2 cents.... If you consider the full capabilities of the system before you design it, then even if you don't want to use those capabilities right now, at least they will be simple to add later. If you build limitations into the system now, they're going to be hard to get out....

[DrBunsen]

An alternative approach might be something like a port of the virtual MIDIbox tools

[fluke]

What do you mean by "the virtual MIDIbox tools"?

I was planning on starting with a simple system for mostly text, so as to offload most of the work from the Core module to the Palm, but still make it general purpose enough that it won't need a fully custom Palm application for each sort of MidiBox.

[DrBunsen]

Serge's vMIDIbox tools - editor/simulators for the older, pre-MIOS/ PIC 18 MBHP projects.  Like a SoundDiver synth editor, Cubase mixer map, Logic environment, a screen full of virtual knobs for editing MB patches over MIDI.  Partly superceded by JSynthLib

[fluke]

Other than my dislike of vitual knobs (sliders are much easier to use with a mouse, only 1 axis to travel), it's possible.  But it's getting out of the "Palm as a display" realm and into the "Palm port of JSynthLib" realm.  Which is something i can't write myself without a Midibox or Palm MIDI interface.  I could help someone else write it though, PalmOS isn't very hard to program for in C and it'll mostly consist of writing handlers to convert button presses into SysEx messages.

[DrBunsen]

Yeah I see your point.  I imagine instead something like a virtual SID step B control surface - the display element, and a small number (5?) of on-screen buttons and one virtual fader, to allow menu selection and parameter editing.  It would still act as a straight display as far as signal from the MIDIbox to the Palm, but it would also send serial signals back to the core identifying button presses and slider movement, which the MIDIbox would interpret as if they were the corresponding hardware buttons coming through a DIN.

[fluke]

That's doable.  I'm still not sure i like the interface though, so i went ahead and wrote it.  It looks like this:

You can download the PRC file from http://one-two-three-four-five.com/palm/sid-b.prc.  It'll need at least PalmOS 3.0, but it doesn't check for it.  Tap either side of the encoder to rotate it.  It doesn't do anything else.

[DrBunsen]

Nice work!  Perhaps making that big knob into a linear slider would give you more room for your other display elements though.

[fluke]

A rotary encoder isn't the same thing as a linear slider though, it doesn't stop at each end.  It's really two buttons, one for each direction.  A pair of buttons doesn't have the same metaphore as a knob on screen though.  Hence my request for someone else to do the UI design. ;)  The knob could be made smaller, i was just using all the left over space.

[TK.]

It works, even on my old Palm Vx :)

But I would also prefer a slider, or better: dedicated menu screens for sound parameter settings with buttons and sliders for intuitive and especially fast usage :)

Best Regards, Thorsten.

[fluke]

So that's 2 votes for a PalmOS port of JSynthLib? ;)

[DrBunsen]

Or something like :)  I imagine trying to run it under Java on a Palm old enough to have a serial port would be a pain.  So I guess it would be more of a native MIOS GUI than a direct port.  Mind you I really am guessing here.  You'd know better than me fluke.

[fluke]

There are ports of J2ME to PalmOS, but they don't have access to the serial port.  JSynthLib won't run on J2ME anyways and the entire interface would need reworking for the small screen.

How about a system where locations of buttons, sliders, "LCD" display, etc and the MIDI command to send are defined in a Memo (or text file linked into the application)?