midiphy SEQ v4+

[nzimas]

Hi everyone!

Before ordering one of these beauties, I would like to know if it possible to test an emulated software version. 

On the Ucapps website it is mentioned that such a thing exists, at least for the V4, but I can't find it anywhere on the downloads section.

I wonder if one must install MIOS Studio 2 first and then load the V4 firmware into it.

Thanks!

[latigid on]

Hello,

The answer is "maybe":

 

Looks like you'll need to compile the code and run it on iPad somehow. No idea how to do it!

MiOS Studio is just a USB interface really. Mostly for uploading firmware or monitoring. The sequencer application as pre-compiled firmware runs on microcontrollers only.

 

[latigid on]

We can track the SEQ v4+ serial numbers here:
https://forum.midiphy.com/d/60-midiphy-seq-v4-official-serial-number-thread/2

[Hawkeye]

midiphy SEQ v4+ user clddstllr created two nice overview and function keys cheatsheets, attached them below - they are also available for download in PDF format on midiphy.com.

Best regards and have a good weekend!
Peter

[slo]

Can someone please confirm that the transpose function is actually working, I'm having a fight getting it working properly. Using G1T1 Root with static notes and Chord parameters into BUS 1, mode on normal, G1T2 track (bassline) mode on Transpose, Note set to First. Settings in Midi/T&A seem to be correct. The output is just octaves of C. I did have this working quite awhile ago, but I cannot get it going now.

[Hawkeye]

@slohave you tried to follow TK.'s tutorial #3 over here?

http://ucapps.de/midibox_seq_manual_tut3.html

From the software side, i am pretty sure the bus transposer hasn't been touched in a while, so i think it should work.

Personally, i've never used bus based transposition, but can confirm, that normal track-based note transposition (with or without force-to-scale) on the standard transposition screen works - here you could also select multiple tracks via the second row and then transpose them all at once, but it's of course not the same as the automated variant linked above.

Many greets,
Peter

 

[slo]

@Hawkeye I have never seen those tutorials before! don't know how I missed that, there is a wealth of info there. Following the tutorial the transpose works, under the scheme laid out in the tutorial. I will try the Root method next and report back. Thanks!

Edited March 4, 2023 by slo

[srmaietta]

Hello!  
 

I know this has been brought up before, but I’d like to revisit the idea of “unquantized live recording”.

currently the quantize percent basically shows how far off one can be before dropping a value in the current step/prev step.  So it’s locked to a hard step position.  I know we can up the resolution and track length to kinda sorta work within the system.  But that is not ideal for a number of reasons.

An idea: when recording midi, if we have the delay parameter assigned on a track, and have quantize set to 0%, it will then drop the played note wherever it was played within the delay parameter resolution.

Perhaps a new track format needs to be set up, or perhaps it is a parameter to toggle in the menu.  
 

I have no idea if this is at all possible from a programming / code base perspective.  But no truly unquantized recording is one of the only missing things of our mighty Seq 4!!!!!  
 

Thanks for reading!

Steve

[Rio]

Hello steve,

Is it possible for you to make your own binary from the sources? I have written a fix for quantized live recording in the past...  you could try the code changes/snippets which it affects. Let me know if you would like to try it out.

Oh, you mean a possibility of an exact "unquantised recording". Of course, my suggestion doesn't fit there. 

greetings,

rio

Edited March 5, 2023 by Rio

[srmaietta]

3 hours ago, Rio said:

Hello steve,

Is it possible for you to make your own binary from the sources? I have written a fix for quantized live recording in the past...  you could try the code changes/snippets which it affects. Let me know if you would like to try it out.

Oh, you mean a possibility of an exact "unquantised recording". Of course, my suggestion doesn't fit there. 

greetings,

rio

Up for any ideas!

[Rio]

this fix refers to the following issue (midibox seq v4 release feedback):

The quantized recording loses its sustain (GLD) due to the offset of the next step, since the note of the step to be played is not passed and the recording loses the (note/sustain) information in the next step.

 

seq_core.c:

1. replace this line:

https://github.com/midibox/mios32/blob/master/apps/sequencers/midibox_seq_v4/core/seq_core.c#L1053

with:

	    if (SEQ_RECORD_NewStep(track, prev_step, t->step, bpm_tick))
                mute_this_step = 1;

mute or not to mute? thats the question!

 

seq_record.c:

2. insert this code:

  if (t->state.REC_DONT_OVERWRITE_NEXT_STEP) {
    int next_step = new_step + 1; // tmp. variable used for u8 -> u32 conversion to handle 256 steps properly
    if( next_step > tcc->length )
      next_step = tcc->loop;

    new_step = next_step;
  }

before:

https://github.com/midibox/mios32/blob/master/apps/sequencers/midibox_seq_v4/core/seq_record.c#L727

 

3. replace this line:

https://github.com/midibox/mios32/blob/master/apps/sequencers/midibox_seq_v4/core/seq_record.c#L735

with:

if( any_note_played ) {

which also passes flagged REC_DONT_OVERWRITE_NEXT_STEP.

 

4. replace this line:

https://github.com/midibox/mios32/blob/master/apps/sequencers/midibox_seq_v4/core/seq_record.c#L843

with:

return any_note_played; // no error

instead of no error code, but it is enough that it is returned positive.

 

Note: It is more of a hack than a concrete fix (it only works for tracks that are played forward), but for my purposes it works - if you actually like to use the quantization feature for live recording.

But your desire to get an "undelayed, unquantized recording" has nothing to do with this solution.

This hack is suitable for a working quantization during live recording of tracks that already contain & process midi data. Maybe quantization can give better results when recording notes, except that it does not conflict anymore with existing (already recorded) data in my modification.

 

Edited April 13, 2023 by Rio

[Hawkeye]

@srmaietta TK. had approached unquantized recording in SEQ v4+ a while ago and i think dropped it due to complexity - the option for unquantized recording is the main reason why we developed the midiphy LoopA.

Many greets,
Peter

[srmaietta]

Thank you Rio, it gives me something to tinker with.  
 

and it gives me insight into the difficulties (as Hawkeye mentions) with changing something that is reliant on many other things in code..

[Anonyme-x222]

Hi,

I would like to add  a remote control option in the external controller section.

seq_midi_in.c

The function static s32 SEQ_MIDI_IN_Receive_ExtCtrlCC(u8 cc, u8 value) need to be modified like this static s32 SEQ_MIDI_IN_Receive_ExtCtrlCC(u8 cc, u8 channel, u8 value)

The call like this:

SEQ_MIDI_IN_Receive_ExtCtrlCC(midi_package.cc_number, midi_package.chn, midi_package.value);

i will have to add :

Mutes By Midi Channel

in the const char* ext_ctrl_str[SEQ_MIDI_IN_EXT_CTRL_NUM] =

However the mute channel part isn't in a case but directly in the root of the function ?

can help ?

Thanks in advance,

Have a good day,

Rgds,

 

 

[Rio]

This should rather be opened in a separate post. 

[k2z3k0]

hi 

did anyone tried that ?
i can make it work with 0..15 but not 127 for currently selected track




 o CC#99 (0x63 - NRPN MSB)
     Selects the Track which should be modified via NRPN
     Allowed values: 0..15 for Track 1-16, 127 to modify the current selected track

seq_midi_in.c says

 

case 0x63: // NRPN MSB (selects track, if >= SEQ_CORE_NUM_TRACKS, take the currently visible track)

    nrpn_msb = value;

    break;