Analogue-sequencer

> That thing with a black upper row and a clear lower row in the 
> display, sounds a little familiar with me.

The LCD display has a CPU of it's own. The P3 CPU communicates with it
over a simple 8 bit wide bus, which has data lines, read/write, enable
and a register select.
The solid line of black, with a clear second line, is a state the LCD
module goes into when gets reset - the P3 shouldn't be sending it any
command that will cause it to do that. Unless of course the processor is
taking a fit...

> That happened sometimes 
> wih my P3, but not when I was ramming the buttons too fast, but when 
> I did something unlogical with a midi-master device, like pulling the 
> din plug while it is running.

If you get this sort of behaviour and you can identify what made it
happen, do please let me know, so I can fix it.
It is possible that some bad midi input might crash P3. I'll review the
reception code and see if it can be made more robust.

> And I got some other questions. First: , I made a sysex dump of the 
> P3's memory without any problem, but when I want to put the memory 
> back in the sequencer I don't know how to tell my sequencer that it's 
> ready, that it has recieved the last block, cause it says: 
> Pattern:170F, but what do I do after that??

You hit abort - that's it done.
The P3 sysex format has 3 types of sysex block: bank/FTS, part and
pattern.
Each part and pattern block identifies it's location in memory.
The sysx send option just dumps the bank/FTS data, then all the part and
pattern blocks in order.
So these blocks can be received back in any number, and any order. There
is no 'end of file' message that tells P3 a full dump is complete,
because it isn't a full dump as such - it's a set of part and pattern
blocks for all parts and patterns.
170F (hex) is last because the first 2 digits show the pattern bank and
track number in 5 bits (2 bits for bank 1 to 3, 3 bits for tracks 1 to
8), and the 0F means pattern number 16.
This should make more sense when I get the P3 memory manager app written
- it will be able to request individual patterns or parts, then write
them back to different locations. I'll be adding sysex messages to
'request to send' part and pattern blocks. In this case, sysex recv mode
will really be a 'terminal' mode, where the PC can interrogate the P3
memory, to allow drag and drop organisation of parts and patterns, with
visual editing directly on the PC. One day...

> Second is not a question about the P3, but I think some people here 
> could help me, so: 
> I'm building a sort of a Master-Clock device, with midi in/out, din-
> sync in/out, time-base out and stuff like that but I till now I have 
> two problems: I don't know how to make a BPM display. I use a 555 
> clock timer chip for the master-clock signal, and can anyone help me 
> designing a circuit for the BPM display. I got a pocket full 
> of '1character displays' with 10 pins atached at the back, and I 
> would like 3 of them for the display.
> Third, also for the clock-thing: I'm looking for a good start/stop 
> cirquit. Now I use a common push to make switch for stopping and 
> starting the machine, but the switch doesn't work right. For when I 
> start the machine, it runs, but mostly it stops immediatly. When I 
> hit the knob it's like the switch switches on and off really fast for 
> several times, and after that the machine runs, or not. 
> I hope you understand what I mean, and that someone is able to help 
> me.

I would strongly suggest using a CPU for this job. Things like
calculating the incoming tempo of a midi clock for display are actually
quite tricky, because midi clock pulses can be quite irregular - you
need to do a certain amount of smoothing to ensure your less significant
digits don't flicker between values. (P3 has rock solid clock, of course
;-)
Once you're smoothing the incoming clock, usually by generating your own
internal clock which you soft sync with the midi clock, then you can do
things like sync doubling easily. P3 does this to generate its 48 ppqn
internal clock from 24 ppqn midi clock.

You may not want to use a CPU because of the need for a device
programmer, but I had an idea a while ago that might help that...
The P3 CPU (T89C51RD2) is a pretty neat part - it has the built in UART,
which can handle midi data obviously, 3 timers, plenty IO pins, 1k
static RAM onboard, and 64k flash. There are many free assemblers for
the MCS51 family, and SDCC is a fantastic C-compiler for the money (also
free).
I was thinking of putting together a little 'MIDI CPU Experimentor'
package, which would include a P3-type CPU, with a non-encrypted version
of the bootloader. This could be easily built into simple circuits, with
a midi interface, and then have your own code uploaded over MIDI, in the
same way as P3 firmware updates, although possibly with a simpler UI so
you don't need an LCD if you don't want one.
The package would include a library of basic midi handling routines,
some other sample code (LCD handling etc), and a version of my
'BinToSyx' utility, that I use to convert intel Hex files output from
the compiler, into the .syx files you can send over midi.
If this sounds interesting to anyone, let me know, and if enough people
would buy one (price probably around 20 - 30 ukp shipped), I'll sort it
out.

Cheers,
Colin f