|
Umm. I don't need to differentiate which is which, I only need to know how far apart they occur.
A MIDI time clock signal is sent 24 times per quarter note.
That's all my tap tempo transmitter does.
The recorder sees these MIDI time clock signals.
Its job is simply to use them to determine the tempo solely based on how far apart they occur, and adjust its tempo accordingly when it sees them.
I don't need to distinguish between different clock signals (like beginning and end). there is no such concept in the MIDI wire protocol anyway.
Real programmers use butterflies
|
|
|
|
|
I was under the impression that you internally used _timeStamp...'s in the internal processing of the main program. In other words, they were already embedded in the stream for timing purposes. Good luck getting to the bottom of everything!
|
|
|
|
|
Windows performs context switches at a pace that I would call manic, so I don't think it would account for the 20 msecs unless there is semaphore contention or something else going on.
|
|
|
|
|
I'm also not using any locks explicitly inside that codepath except when the tempo changes, which doesn't happen *between* messages
Real programmers use butterflies
|
|
|
|
|
If you visit QA much, you'll recognise this ... Modern Art[^]
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Bought right!
I'm not sure how many cookies it makes to be happy, but so far it's not 27.
JaxCoder.com
|
|
|
|
|
He also needs the answer ASAP.
|
|
|
|
|
Too good!
|
|
|
|
|
... (thru' with the two step)
|
|
|
|
|
Does a clock radio go off with alarming frequency?
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Not something I toc about very often, but if so, it snooze to me.
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
That one just Hertz, period.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
OriginalGriff wrote: Does a clock radio go off with alarming frequency?
every time.
|
|
|
|
|
Only if you leave it out of the fridge... ?
|
|
|
|
|
Since most clock radios use a really annoying high-pitched beeper for the alarm sound, yes they do.
Those among you notice the 'meta' nature of this reply should discuss amongst yourselves while everyone else catches up.
Software Zen: delete this;
|
|
|
|
|
If a clock radio goes off - why is it that the first thing everyone does is turn it off?
Wait - is this back to the no-no thing?!
If you can't laugh at yourself - ask me and I will do it for you.
|
|
|
|
|
|
Accessing a hard disk with an 8 bit processor is a slow affair. No matter how modern that drive may be, you will never get your bytes faster than the processor and the bus can shovel them in.
Serial ATA is no option, simply because my UART and the bus can't keep up with the minimum bit rate. Not by a long shot.
Ok, then it's good old parallel ATA/IDE. The problem here is that even the oldest specification requires a 16 bit data bus. You can use it with an 8 bit bus, but then the upper 8 bits of every 16 bit word would be wasted. You would lose half of your drive's capacity. Since this was last seen on old IBM XT era computers, I also doubt that any reasonably modern file system can live with that.
A common way around this is to put a parallel port between the processor and the drives. That solves the 16 bit problem, but then things get really slow. The processor is more busy with the port's control and data registers than actually sending or receiving bytes. Remember the C64's floppy drives? That sort of slow.
Now, it looks like my little processor's bus is compatible with the drives' controllers. I might even get it to work in DMA mode, speeding up things instead of slowing them down. And I would waste half of the drive's space.
So, what option should I go for? And what file system should I use? FAT16 (or similar) would be the minimum, better FAT32.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
How about something like this[^]?
I'm not sure how many cookies it makes to be happy, but so far it's not 27.
JaxCoder.com
|
|
|
|
|
I wish it were that easy, but setting up the tiny computer as USB host is even more complicated.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
modified 1-Jul-20 10:16am.
|
|
|
|
|
I know it's complicated but this [^] might help.
I'm not sure how many cookies it makes to be happy, but so far it's not 27.
JaxCoder.com
|
|
|
|
|
Quote: it includes no PC host USB driver development facilities
Sounds like the microcontroller is set up as USB client with a PC as host. I would have to set up my coputer as the host, and that might be a little more complicated. Let me first build something that can load and boot an operating system before I write the OS itself.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Never used LUFA and know little about it but I have seen a lot of people use it and thought it might help.
I'm not sure how many cookies it makes to be happy, but so far it's not 27.
JaxCoder.com
|
|
|
|
|
I doubt that any older 8 bit CPUs would make a good USB host. The old UARTs or USARTs don't even support the minimum bit rates and even with DMA you would struggle to get that stream of bytes through the bus in real time. Clients like a USB mouse or keyboard, which only snd a few bytes at a time, may be ok, but nothing that sends larger streams. As cool as USB might be, but I'm not sure if the effort to build it would be worth it, even if the lower bit rates are a lesser problem.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
CodeWraith wrote: And I would waste half of the drive's space.
With today's large drives, wasting half of the drive's space isn't a major issue today. The question is compatibility - (1) will any platform other than yours be able to read the disk, and (2) do you care?
I'm sure that circuit diagrams exist for the PC/XT's 8-bit disk controller and for other disk controllers of the same vintage. If that supported disks with a 16-bit bus, could you not cobble up something based on them to perform the 8-bit to 16-bit transfer?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|