idea for new MBHP module!

[Guest memon]

Final scratch is great, but it's expensive, and IIRC works only under Linux (not 100% sure...).

My mouse-dj project got started when I though about how to visualise a DJ playing records. The usual way is to analyse the output of from the mixer, and draw something nice according ot that. I wanted to track the movement of the DJ instead of the sound.

The optical mouse is not a precise instrument to measure anything, but it works relatively well. I will need to be positioned well, and the output needs some filtering. The mouse I have (or the mouse driver) seems to use some kind of error diffusion for the values, so the values are a kind of sawtooth like, but it can be filtered to something nice :)

The mouse can only be used to track the movement of the surface benath it, so it's not as fancy as the final scratch is. In FS you can move the needle and the software will play the "virtual record" at that position too.

I'm willing to provide some help if someone decides to make the mouse driver for MIOS. Unfortunately I dont have the time to do it myself.

[sil909]

Hello alll, hello duggle.

  Was wondering if any new updates to this projects could be posted.  Thinking of incorporating this into  my set up.

Thanks in advance.

[SounDuke]

hey things are growing fast! another year and MIDIBOX opensource project will be attacked by synthesizer corporations, parallel to what happened between Linux and Microsoft  ;D

ROLAND VS Thorsten Klose and his gang of mad electricians!

[adamjking]

Hi Memon,

I'm not sure if you've used it or not, but terminatorX http://terminatorX.cx does pretty much exactly what your project does. It runs under Linux/FreeBSD and allows you to "scratch" digital files with a mouse. Fans of the program (including myself) have modified turnatables to hook up to a mouse, as seen in the gallery http://terminatorx.cx/turntable.html.

I am now working on a full MIDI controller mixer/turntables for use with the program ;)

[stryd_one]

The keyboard adpator I'm planning at the moment is to accept serial data from a standard PC AT Qwerty and convert it into IIC slave interface for connection to a MIOS core.

It will be based on the low cost PIC16F84 (18pin device),

programmable from a JDM. Once constructed it is unlikely that the firmware will ever need change. All user options and functionality are provided by the MIOS Midibox it is connected to.

If someother exotic keydevice is wanted, I suggest to cut tracks(!) and wire keyboard switches to DIN module(s).

I'll be oherwise very busy for a few weeks, then I expect to implement it quickly. I'll post back here when more news.  

cheers

Alright then! Nice work duggle!  :D

Will we be able to chain devices, say use two keyboards? How will the device interface with the core module?

Also, why did I not realise that this post is really old!? hehehehe

Duggle? are you still there?  ;)

[Duggle]

hi, yes I lurk from time to time ;)

I'm really busy with study these days but I would like to "finish" this one during my midyear break.

I have implemented ps/2 I/O functionality (for keyboard and mouse) as well as midi-merge. I have a bit of debugging to do but the idea is to have (1xCore) support up to 4x ps/2 ports (for say 2 kbds, 2 mice ) and a midi in and midi out

With the midi merge function system integration is really easy as you just cascade control surfaces as many as you want. You set up your host application to do what you want with the midi events.

So the IIC I/O becomes less important given that midimerge will allow integration fairly well for most users.

I guess its still a couple of months before I can look at it again.

cheers

[sil909]

Here is a link to some IIc info regarding PICs.  Might be helpful  its about  a quarter of the way down the page

http://aid.interaccess.org/drupal/?q=book/view/22

[moebius]

I have implemented ps/2 I/O functionality

But no ps/2 output?

I guess this could be useful: Like for processing keyboard input and manipulating it, Like:

a. creating keypress macros

b. midi -> keypress, like using rotary encoder for inc/dec values normally done with keyboard..

??!

Bye, Moebius

[machinate]

I have implemented ps/2 I/O functionality (for keyboard and mouse) as well as midi-merge. I have a bit of debugging to do but the idea is to have (1xCore) support up to 4x ps/2 ports (for say 2 kbds, 2 mice )

you can get ps/2 compatible surplus touchpads for about 5€ all over the place, imagine hooking four of them up to a core! A ps/2 output would be useful as well, so that integrating "normal" touchpads and so on into our projects could be realized without leaving the midibox world.

Can't wait to see what you come up with!  :D

Andreas

[Duggle]

Hi,

Ive made a surge of progress over the last 2 weeks and now have basic functionality of auto detecting and decoding any combination of mice and keyboards into basic midievents. The midimerge port provides passthrough of an external midi source (no sysex passthrough yet).

I am currently refining the I/O engine to handle worst case throughput without errors. (Average case throughput is fine). I will also look at supporting a wider range of devices.

Does anyone have specs on the toughpads? (Do they look exactly like a mouse to the ps/2 interface?)

I'm interested in info on any other kind of PS/2 device midiboxers may want to input with a view to including as many devices supported as possible.

Unfortunately I have a very busy 6-8 weeks ahead so progress will slow a little, however the release of this code and various h/w versions to the midibox community later this year is assured!  (hey, Ive been on this ps/2 "hobby horse" for nearly a year and I ain't stopping now!  :D)

cheers

[Rednas]

Liked the idea so much I made one. :) Had a C64 keyboard leftover from my MBHP_SID project.

I don't know MIOS well enough yet, but I'm sure you could do the 8 by 8 matrix on the core module.  You wouldn't even need a multiplexer (unless you wanted to save pins)

Right now I just have the keys mapped to midi notes and patch changes, but I'm thinking of making it more complex.  

I can post more details later if people are interested.

Christopher.

Mios already has an implementation of an 8x8 matrix. JimHenry is currently working on a 16x32 matrix, for the huge amount of witches the midiorganplayer uses (two or three keyboards, pedal board stop switches, prestet switches...)

I think in this there will be room to asign a midi message to each key before burning it to PIC. Not as easy as MIDIO128 in the beginning, but good enough and easier to program. You can probably use part of this matrix connections for the commodoreC64 if the C64 also uses an 8x8 diode matrix. Or if you can't wait use the 8x8 matrix implementation.

I think I'll go and find out what this C64 is (I'm not a SID builder) and take an extra look in my keyboards :-) )

[Guest Mark420]

any news on this project?

I am very interested in working with a  touchpad or mouse system.

Regards

Mark ;)

[ryan.shuck]

Awesome.  My joystick replacement system will work wonderfully with this.

[machinate]

Bump!

I already ordered a gazillion buttons for my next project, but I'd still love to see a 4 ps/2 keyboard interface - Duggle?

[TK.]

Duggle sent me a beta version some months ago, it works fine!

Best Regards, Thorsten.

[Ysv]

Hi Thorsten, I have a design that might really benefit from something like this (ability to hook up a keyboard). Is it possible to get schematics for this? Is there a module under development?

[Duggle]

Hi, I'm through my exam period so I have some time. I did some more work on this since the version Thorsten tested. I do plan on finalising a mode for use with MBSEQ (single ps2 keyboard events activate midi-key combinations for MBSEQ remote) then releasing the design and firmware for anyone interested. At the moment there is a bug that occasionally causes the a PS2 port to stop functioning (quite rarely). Until this is fixed I would not use it for live performance! ;)

To recent posters on this thread (sorry, I've not been here for a while...) personal message me and we can arrange for a beta version test.

cheers

[machinate]

Hello again, I hope the exams went well? Anyway, I would love to help out with the testing, but I am too much of a novice to do anything useful, I think  ::)

[Ysv]

I have a design that would benefit greatly from a module such as this one. I've never built a Midibox before or any electronic device for that matter so I don't think I would be beneficial as a beta tester other than putting the module into practice.

If I end up building without this type of capability then I am looking at connecting buttons using 2, 4x4 AIN's. My main question is in terms of parts and PCB availability. Are these things available at Smash.tv or would they need to be built to spec using parts from multiple suppliers? How complicated is the design to fabricate?

[bill]

Hello duggle, how are your exams ?

Any news of your project ? We cant wait !!!  ;D

Greetz

[tos]

Ok, so here is the idea: you can take some old turntable, fixate it's Platter and make a hole for a mouse optics, stuff all that inside and then put some old record ontop and sratch away.

I neeed that mouse interface. Hope it's doesn't need an extra CORE and can be implemented within existing projects [i'm shooting at MB64e here :) ]

Ad how come I've stumbled upon this tread this late....hm....must be some of that evil Microsoft influence.

[stryd_one]

How would that differ from any other encoder attached to a turntable?

Keep in mind that MIDI lacks the resolution to be of much use for turntablism.

[tos]

It differs, all of you are skipping a point here, when you scratch, you dont move the turntable platter, ony the record. Thats what mats are for, they go beteen the platter and a record.

The midi doesn't have enough resolution, right but what if you are sending only the offset.

This new idea of mine should be tested/benchmaked:

One optics to read the movement[speed, whatever] of the platter and second for reading the movement of the record. Divide them, trim them down with some constant [i can adjust the code] and you can send the offset in speed beween thiese two. Offcourse you would be needing a turntable with a working motor [or something rigged "just-to-work"].

[stryd_one]

No need to measure the speed of the turntable because that could (and should) be constant - like you said, that's what slipmats are for.

The midi doesn't have enough resolution, right but what if you are sending only the offset.

This is an interesting concept and might just work. Of course you have to have software that supports skipping back or forward by a defined distance, do you have that?

You don't need to send the offset between platter and disc (as mentioned above) but just how far the disk was moved... Of course then you have to decide what unit of measurement to use, as you could use time on disc or distance in degrees (which obvious differs depending on the needle position) or lord-knows-what.

Then you have to think about what to do with acceleration... do you send a byte every x milliseconds to show how it moved, or do you send a byte showing the time taken between a given distance of measurement, or.....

I'll let you think about this stuff and come back to us.

Uhm, maybe I'm missing something, but wouldn't real vinyl be easier and cheaper and sound better?

[tos]

stryd you ar a willy one but your willynesnesnes gos the other way than mine.

If the platter is moving at measured speeed X and we add a constant C1 to it so it would be equal to 64 and then we do the sam with measured speed of the record (Y+C1-/+C2) to

align thiese two inaccurate measuring devices [two optical mouses] and then we take into accout the glitches so let's sat +/-2 to difference between a values you get the stable system without changes:

  X+C1 = 64 = Y+C1-/+C2

Why do we have to do this: bkz we need to know when someone lays hand on our record. See CDJ-1000 has a touch sensitive surface [or more probably a touch sensor] on the platter We....don't. We measure offsets. I know it is the hard way but I can't see your way working and I also can't see my way working without a nice test/benchmark. So when someone stops the record the right side of equasion goes some way (up/down)...and a kontroler starts sending messges, what kind od messages, the Traktor compatible wind messges. +64/-64 depending on the speed offset between the platter and the record. There would be no measurment of the needle position [i have no need of replicating NI FS] Also Traktor has a specialized input options:

-MIDI - Incremental
This should be checked for controllers sending incremental messages
(endless knobs). If checked, three further parameters will be offered:

-MIDI - 4 Control Mode
Use this option to assign the NI 4 Control MIDI hardware incremental
mode to a knob.

-MIDI - Sensitivity
Determines a fixed transmission ratio between hardware knob and
software parameter (at zero acceleration).

-MIDI - Acceleration
High values of acceleration exaggerate the knob’s speed - the faster the
knob is turned, the more quickly the rate of change in the parameter.
Conversely, turning the knob slowly will allow finer tuning of a parameter.

To be honest I can't be sure what combination would work in this scenario but I believe it is do-able.