[TK.]

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



Best Regards, Thorsten.

[Narwhal]

I'm a registered and active iPhone/iPad developer and I have an iPad here if you'd like me try out some code.

Kurt

[TK.]

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.

[findbuddha]

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

[TK.]

Quote

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.

Quote

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.

Quote

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.

[findbuddha]

TK., on 17 April 2010 - 14:45, said:

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. 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

This post has been edited by findbuddha: 18 April 2010 - 06:20

[TK.]

findbuddha, on 18 April 2010 - 06:16, said:

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.

[Narwhal]

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

[gjvti]

TK., on 17 April 2010 - 14:45, said:

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

Best Regards, Thorsten.

BTW here is comparison chart of abailable/available soon touchpad devices

Best regards
Gunars

[Schrittmacher]

wow thorsten ...

I tried in the past this nice programm
IPMidi


This work very fine with all computers with ethernet and ipmidi.


greets.. Marco

[Narwhal]

Schrittmacher, on 19 April 2010 - 23:24, said:

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.

This post has been edited by Narwhal: 19 April 2010 - 23:42

[Narwhal]

Success. Video on the way.

This post has been edited by Narwhal: 20 April 2010 - 00:31

[bugfight]

wayyyy cool, now i just have to wait for the next gen ipad and/or radical first-adopter-screwing price drop

[TK.]

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.

[Narwhal]

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?

This post has been edited by Narwhal: 20 April 2010 - 01:10

[Schrittmacher]

Narwhal, on 19 April 2010 - 23:40, said:

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!

[Schrittmacher]

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

[TK.]

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.

[Narwhal]

TK., on 20 April 2010 - 18:58, said:

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.

This post has been edited by Narwhal: 20 April 2010 - 20:12

[TK.]

Ok, so it's probably better to remove this file (remove the reference only!) from the compile list - in this case, the non-optimized libc printf() functions will be used.

Best Regards, Thorsten.