Jump to content

Virtual MIDIbox SEQ V4 for iPad


TK.
 Share

Recommended Posts

Here a first impression of the virtual MIDIbox SEQ V4 for the iPad.

As you can see, there is some space for additional buttons or display functions. :)

Due to the delayed delivery in Europe I won't be able to test and finish the emulation before june...

Currently I cannot estimate if the timings will be so stable like on a real MBSEQ, however together with the upcoming OSC option we will get at least a nice remote control :)

vmbseq_v4_alpha1.png

Best Regards, Thorsten.

Link to comment
Share on other sites

  • Replies 83
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

You can download the code from the command shell with "svn co svn://svnmios.midibox.org/mios32"

The project file is located under trunk/apps/sequencers/midibox_seq_v4/ipad/MbSeq.xcodeproj

It would be especially interesting if the virtual encoders are working properly.

Note that MIDI output isn't implemented. I've heard that MIDI is provided via Bonjour, but haven't found documentation about this approach yet.

Best Regards, Thorsten.

Link to comment
Share on other sites

TK,

I'm curious how you see the role of touchscreen devices for the purpose of implementing largish BLMs (say 16x16)?

I've got my SEQV4 nearly finished (just waiting on front panel/case), and I'm not sure in the future whether to choose hardware or software BLM.

Also I wonder if there will be cheaper touchscreen devices than the iPad, that still provide a useful interface.

Cheers :)

Link to comment
Share on other sites

I'm curious how you see the role of touchscreen devices for the purpose of implementing largish BLMs (say 16x16)?

Well, when I saw the first iPad videos my first idea was, that this is the ideal platform for a virtual BLM, not at least because of the multi touch capabilities which is the key for such kind of applications.

I've got my SEQV4 nearly finished (just waiting on front panel/case), and I'm not sure in the future whether to choose hardware or software BLM.

I'm not sure if I still need a HW based BLM for myself anymore.

The main advantage of the SW solution is the flexibility - you can quickly change the application to use the device for a different purpose, accordingly it saves some place on the desk.

Beside of the virtual MBSEQ and BLM I'm also planning a flexible MIDI keyboard interface which changes its layout based on a selectable scale (only notes which are part of the scale can be played). Such a keyboard is impossible to realize in HW. ;)

Another application will be a SysEx editor for MBSID - probably it will use the same code as MBSID V3 which will feature a touchpanel as well (but much smaller and w/o multitouch)

So - these are already 4 useful applications that can run on the same device. :)

Also I wonder if there will be cheaper touchscreen devices than the iPad, that still provide a useful interface.

I don't know a similar device in this price range with the appr. display size which supports multitouch

Best Regards, Thorsten.

Link to comment
Share on other sites

I'm not sure if I still need a HW based BLM for myself anymore.

The main advantage of the SW solution is the flexibility - you can quickly change the application to use the device for a different purpose, accordingly it saves some place on the desk.

I understand what you mean - software is so flexible. I wonder if the responsiveness of the iPad's touchscreen will provide for a satisfying experience? I assume it will be fine for non-timing critical button pushes, not sure about things like virtual encoders and XY pads etc. This also requires good latency from the WiFi OSC connection.

Unfortunately for me I think the iPad will be more expensive than a hardware 16x16 BLM (discrete button + led, not illuminated buttons), and I have no other reason for getting an iPad. :frantics: I'll have to work out total cost of all buttons, leds, PCBS and extra panels/casing from Ponoko.

If I'm going to buy a tablet device I'd also like better connectivity options than the iPad offers - we'll have to see what HP, Google etc. bring out.

Do you still plan to add the code to support the hardware 16x16 BLM?

Cheers :)

Edited by findbuddha
Link to comment
Share on other sites

Do you still plan to add the code to support the hardware 16x16 BLM?

The code to communicate with a BLM via MIDI is already integrated into the MBSEQ firmware and tested (with the virtual BLM).

It won't be possible to connect a BLM16x16 directly to the MBHP_CORE_STM32 module which runs the MBSEQ firmware, therefore a second uC (a PIC) will be required.

The BLM code which runs on a PIC has been started, but currently only supports 4x16 since I don't have a 16x16 HW ready yet to add and check the required changes.

The project isn't documented yet, and it definitely needs some more work before somebody could start to build the project.

Since I've already the required 256 buttons and Duo-Colour LEDs, I will build at least the basic HW on veroboards (nice relaxing work ;)).

More informations (schematics, configuration options, etc.) sooner or later in a separate topic (not here!)

Best Regards, Thorsten.

Link to comment
Share on other sites

An iPad app that I'm using named AC-7 Pro is a Mackie Control emulator uses a Mac client called DSMidiWifi to receive from the iPad and transmit over virtual midi ports. It also used a midipipe setup to alter some messages. So from that it seems like running a client on the mac is necessary, but bonjour does seem like it would be a whole lot cooler.

I'm at a developer conference called iPadDevLA this weekend, but I'll test out that project later today or tomorrow.

Kurt

Link to comment
Share on other sites

I tried in the past this nice programm

IPMidi

Interesting app, but 79$!?! yikes. It can't be that hard to recreate it. Source for it would be needed to make use of that protocol on the iPad. I say we create an open MIDI UDP and TCP/IP Standard if one does not already exist. The proprietary stuff is ridiculous.

BTW: I've been trying to get the iPad project to build for the device and oddly it has compile errors when device is selected. There is some crazy stuff you are doing there TK and I think some of the C to Obj-C bridging might be a little wrong from what I've been able to tell so far. I'm continuing to look into it, but I need to do some work for a client this evening, so I may have to pull myself away.

It runs just fine in the simulator, but with this Mac Pro its hard to tell how much it will slow down on the actual device.

I'll post some video when I get it going.

Edited by Narwhal
Link to comment
Share on other sites

Very cool, thank you for the remote demonstration! :)

I already feared that the GP knobs are too small, but I will try to improve the touch handling with tap and stretch gestures.

As a workaround, you can already use the big datawheel to change the last selected value.

By pressing the play button the sequencer should start - thereafter press the menu button, select "Info" and you should get a "stopwatch" value which tells you how long a sequencer update cycle takes. On the Core32 module it typically takes ca. 600 uS..1.5 mS (value depends on the amount of notes that are played in parallel)

I noticed in the video, that the response of the buttons is sometimes too slow (resp. sometimes they don't switch) - probably the LCD emulation consumes too much time and therefore has to be optimized.

Too bad that the UI doesn't provide priority task handling like FreeRTOS - this would simplify things a lot.

Best Regards, Thorsten.

Link to comment
Share on other sites

The response seems fine, but my fingers are big and those buttons are small. 40x40 seems to be the UI standard to iPhone and iPad. Seems like there is lots of space for UI options here. It would be fine if the LCD encoders were buttons and the main knob was all you turned.

Notes:

I had to comment out the two sprintf's, and snprintf to get it to build for the device.

The right LCD is corrupted when it starts, but seems to fix up when you press any buttons or encoders over there.

The app crashes when I let it sit.. memory leak?

Edited by Narwhal
Link to comment
Share on other sites

Interesting app, but 79$!?! yikes. It can't be that hard to recreate it. Source for it would be needed to make use of that protocol on the iPad. I say we create an open MIDI UDP and TCP/IP Standard if one does not already exist. The proprietary stuff is ridiculous.

BTW: I've been trying to get the iPad project to build for the device and oddly it has compile errors when device is selected. There is some crazy stuff you are doing there TK and I think some of the C to Obj-C bridging might be a little wrong from what I've been able to tell so far. I'm continuing to look into it, but I need to do some work for a client this evening, so I may have to pull myself away.

It runs just fine in the simulator, but with this Mac Pro its hard to tell how much it will slow down on the actual device.

I'll post some video when I get it going.

The MacOS Client is for free!

Link to comment
Share on other sites

Ok, so far! I saw the Youtube Video an i think the Knobs Solution won´t work for (Wurstfinger) wide-fingers.

It´s a Touch Panel..... why not touch direct into the MBSeq Display. A tap on a note in the Display poups a dialog to choose the right note. A dropdown dialog!

This creates more Space for other important Buttons!

Only a suggestion!

Nice works TK.... looking forward until the Ipad Launch in Europe

Marco

Link to comment
Share on other sites

Yes, different page views for more comfortable parameter entry makes sense and they are easy to realize.

I guess that at the end the "HW frontpanel" view will only exist for historical reasons ;)

Memory leak: I will check this once I get my hands on the real device - otherwise debugging will be too time consuming.

It's strange that printf() etc. are not working - the simplified version is implemented in printf-stdarg.c

Best Regards, Thorsten.

Link to comment
Share on other sites

Yes, different page views for more comfortable parameter entry makes sense and they are easy to realize.

I guess that at the end the "HW frontpanel" view will only exist for historical reasons ;)

Memory leak: I will check this once I get my hands on the real device - otherwise debugging will be too time consuming.

It's strange that printf() etc. are not working - the simplified version is implemented in printf-stdarg.c

Best Regards, Thorsten.

It seems that the sprintf parameters conflict with something. Here are the errors it gives (I've shortened file paths):

../../../../mios32/common/printf-stdarg.c:205: error: expected declaration specifiers or '...' before numeric constant

../../../../mios32/common/printf-stdarg.c:205: error: expected declaration specifiers or '...' before '__builtin_object_size'

../../../../mios32/common/printf-stdarg.c:206: warning: conflicting types for built-in function '__builtin___sprintf_chk'

../../../../mios32/common/printf-stdarg.c:214: error: expected declaration specifiers or '...' before numeric constant

../../../../mios32/common/printf-stdarg.c:214: error: expected declaration specifiers or '...' before '__builtin_object_size'

../../../../mios32/common/printf-stdarg.c:215: warning: conflicting types for built-in function '__builtin___sprintf_chk'

../../../../mios32/common/printf-stdarg.c:222: error: expected declaration specifiers or '...' before numeric constant

../../../../mios32/common/printf-stdarg.c:222: error: expected declaration specifiers or '...' before '__builtin_object_size'

../../../../mios32/common/printf-stdarg.c:223: warning: conflicting types for built-in function '__builtin___snprintf_chk'

{standard input}:unknown:Undefined local symbol L_MIOS32_COM_SendChar$stub

{standard input}:unknown:Undefined local symbol L___umodsi3$stub

{standard input}:unknown:Undefined local symbol L___udivsi3$stub

distcc[78163] ERROR: compile ../../../../mios32/common/printf-stdarg.c on localhost failed

I'm not sure what those __builtin___* functions are, or why they only conflict when building for the device.

On the possible leak, I think it took about a half hour before it quit.

Edited by Narwhal
Link to comment
Share on other sites

Interesting app, but 79$!?! yikes. It can't be that hard to recreate it. Source for it would be needed to make use of that protocol on the iPad. I say we create an open MIDI UDP and TCP/IP Standard if one does not already exist. The proprietary stuff is ridiculous.

Hello,

ipMIDI sends simple raw MIDI data over Multicast UDP. The protocol is not proprietary.

Example source code:

http://llg.cubic.org/tools/multimidicast/

ipMIDI OSX is freeware

79$ is the 3-client windows version.

I am not experienced with iphone/ipad development.

With Windows notebooks I had problems with the power saving modes of the WLAN NICs. If enabled you can expect a high latency.

Kind regards

Daniel Schmitt

nerds.de

Link to comment
Share on other sites

Guys, there is no real need to discuss about MIDI options via ethernet.

As mentioned before, there seems to be a standard solution for the iPad provided by Apple.

Alternatively, I've already developed a OSC->MIDI proxy which is really simple to use and which will very likely also run on the iPad.

Here the MacOS and Linux version for example: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Ftools%2Fosc_midi_proxy%2F

A more general version (based on Juce) will be developed so that it also runs under Windows w/o adaptions.

Main advantages: you can send other OSC messages to the same port (-> more flexibility)

It will be compatible with the OSC option of MBSEQ

And there is a separate HW based OSC->MIDI proxy: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fmisc%2Fusb_osc_midi_cv_proxy%2F

Thats the most flexible solution, no?

Best Regards, Thorsten.

Link to comment
Share on other sites

Guys, there is no real need to discuss about MIDI options via ethernet.

As mentioned before, there seems to be a standard solution for the iPad provided by Apple.

OSC would certainly work, but as you've documented elsewhere its a bit slower and is certainly a much thicker wrapper over the midi data than ipMIDI, which looks really awesome to me. Right now, I think any midi iPad apps that I work on are going to use that.

What I was trying to say before is that there is no standard solution provided by Apple that I can tell of. At the time I wasn't really sure, but having just looked at "Core Audio Overview" in the iPhone documentation set, it clearly shows that CoreMIDI.framework, and CoreMIDIServer.framework are not available on the iPhone at all. Crazy huh. Yes OS X has a standard MIDI to Ethernet component, but its not available to even be accessed by mobile devices other than laptops. So this is why the one iPad app that I have right now uses DSMidiWifi.

Edited by Narwhal
Link to comment
Share on other sites

If ipMIDI becomes a defacto standard, it shouldn't be a big problem to provide it as an alternative option. The protocol is simple but primitive compared to OSC. I guess that the transfer performance is almost identical.

This is a controller which uses the Bonjour based protocol: http://futuremusic.com/blog/2010/03/23/midipad-announced-first-dedicated-wireless-midi-controller-for-apples-ipad/

According to the german introduction, no other iPhone/iPad application uses it yet, but the big advantage should be Plug&Play (no driver installation required)

Best Regards, Thorsten.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share


×
×
  • Create New...