Jump to content

Antichambre

Programmer
 View Profile  See their activity

  • Posts

    1,291

  • Joined

  • Last visited

  • Days Won

    101

 Content Type 

Posts posted by Antichambre

  1. 19" Rack MBFM with extended frontpanel

    in MIDIbox FM

    Posted · Edited by Antichambre

    @Thomasch it's clear now... Rows are matriced, Columns are not.
     

    17 hours ago, Thomasch said:

    I wired all Vc connections to the bus, is that ok or should i use ground symbols instead of connecting Vc to the bus?

    I suppose you talk about Vs instead of Vc, and yes it's a ground, you can connect Vs bus to ground or Swithes pin directly to ground, it doesn't matter.

    You can maybe put all the ICs(DIN/DOUT) on this PCB, and connect your CS directly to the Core. It will be cheaper, it will take less space and limit the number of interconnections.

  2. 19" Rack MBFM with extended frontpanel

    in MIDIbox FM

    Posted

    5 hours ago, Thomasch said:

    I have a question regarding Eeschema (i use KiCad).
    I wired all Vc connections to the bus, is that ok or should i use ground symbols instead of connecting Vc to the bus?
    I ask, because i have no clue, if Kicad might build it's ratnest differently, when it has to wire a ground line, or maybe theres any other reason i didn't tink of, not to wire Vc to a bus.

    MBFM_Frontpanel_PCB_ v.03.pdf
    MBFM_Frontpanel_PCB v.03.sch

    Seems to be matricing... Could you explain how you connected the leds and switches, which example did you take?(There is a lot here, try BLM as keyword search).
    I don't understand why some of the switches are connected to 3 busses and Vc which seems to be... a ground? it can't be with a matrix connection. :/
    There's maybe a misunderstanding, you don't need to connect both 'normally open' terminals, check the datasheet cause they are often internally connected and used for PCB routing ease, anyway you need only one terminal.
    Seems to miss some diodes for the switches too, there's no pull-up resistors but they are maybe close to the ICs and on an other diagram.
     

    @latigid on is better than me for BLM stuff it might be more clear for him ;)  but @Thomasch better if you explain a few first...

    Best

  3. 19" Rack MBFM with extended frontpanel

    in MIDIbox FM

    Posted · Edited by Antichambre

    1 hour ago, Thomasch said:

    This sucks a little bit, because it will need more space for additional screws and some additional pinheaders.

    When you design a 'control surface' PCB, first thing to think about is the different height of the components, pots, encoders, button+caps and screen. By changing the part (e.g. EC12) and/or reference within the part(e.g. EC12E1220407) you can try to make them match

    This must be considered first with stand-off length, panel thickness etc... now you know. ;)

     

    1 hour ago, Thomasch said:

    It's a MIOS8 core on a PIC18F4585.
    Maybe @TK. can tell us if it might work?

    But he didn't reply after I don't know if it was working for him.

    Best regards

  5. midiphy SEQ v4+

    in MIDIbox SEQ

    Posted

    5 hours ago, secrethero303 said:

    Its not perfect, but it certainly makes a big enough difference for me.  I'm happy with the result.

     

    (and I guess #18 is me then?)

    That's what I finally did too, that's what I wanted, it's clearly enough.
    But it should not be done with the transparent Keycap, the result is bad and ugly.

    Yes #18 congratulation :cheers:a>

  6. The HAARP, a Hardware Advanced Arpeggiator.

    in MIDIbox User Projects

    Posted

    42 minutes ago, weasel said:

    this would be so awesome! you could just use your piano roll, and map c1 to the first pressed key, c#1 to the second pressed key etc etc.

    Or enter the note sequentially like any old synth do, don't worry i know how ;) I already through about this feature and consider the architecture for it too since the beginning, I want it too, but It's a step by step work.
    Once I publish it, anyone can enhance it, And I will be very happy about this, thankful too. You really have to go into the MIOS32 if you already use an Arduino, and have some coding knowledge,it is not so much more difficult. I don't deserve anything, this OS is made for music.
    You want a bpm generator, here it is, you need a button and led matrix here too, you wants potentiometers to you project, no problem etc... everything is already there and ready to use.

     

    1 hour ago, weasel said:

    does your arp currently support gaps/silent steps or only via velocity 0?

    Not for moment, I though about this too, we can define note number 0 as a silent note and treat like  only for the MODE 'User Pattern" feature we mention above

     

    1 hour ago, weasel said:

    gate values bigger than one step can be a lot of fun and create overlapping poly notes, or legato mono notes. ableton goes up to 200%, maybe even up to 4 steps length though? right now it looked like yours ends at one full step length w no overlaps.

     

    1 hour ago, weasel said:

    they seem to add what looks like random timing jumps in the video

    For overlap(Poly)This is a MIDI voice feature only, they can control CV/Gate too. But a polyphonic processing to control multiple CV/Gate is possible.
    I use the sequencer module and midi note are scheduled so you can set it by the length you want, they are not limited by the mechanic of the arpeggiator and the step length.
    Some sub parameters for each section or panel parameters will appear when the SECTION MENU pages will be available, like for RATE normal/triplet/dotted filtering for the potentiometer to jump over these timing periods, and avoid timing mistakes for real-time too and create good snapping effect for example ;)
     

     

    1 hour ago, weasel said:

    i didn't fully understand your offset and delay parameters

    yes i forgot to show them.
    OFFSET is within the range of +/- the arpeggio note length, with it you shift the note in the steps, but the notes keep their order in fact you just select the note to start with.
    DELAY, it delay the whole arpeggio sequence in the range of a step duration.

     

    1 hour ago, weasel said:

    LOVE that. having an option to add some kind of randomness/humanize to both timing and velocity is a very big feature of an arp . maybe think about a (hidden shift) function to add some random to velocity, or alternatively to the regen/target. i do this all the time on my arps in ableton. you could also implement this for the CV ins you are mentioning i guess, just CV control the delay time or the target velocity level with a random LFO, was that the idea you had for the CVs?

    Each panel parameter will have their CC number and an associated modulation CC number, all accessible from the CV In too, it's MENU things.

     

  8. The HAARP, a Hardware Advanced Arpeggiator.

    in MIDIbox User Projects

    Posted · Edited by Antichambre

    1 hour ago, weasel said:

    I have one question which i couldn't answer watching the video: my favourite feature in an arp which unfortunately isn't realized in many is a melodic pattern relative to the pressed keys. there is a m4l plugin that does exactly this, http://www.maxforlive.com/library/device/3545/arpeggio-designer

    This feature can be easily considered. we can add some 'USER Patterns' in the MODE parameters. I will give it a try when I will add other Modes like converge/diverge etc...
     

    1 hour ago, Zam said:

    Is there any code modification for various MCP320x in muxed configuration ?

    Like it is, the AINSER module works only for MCP3208, there's no define for this point, but it's possible to enhance it for MCP3204 and 3202, you must read only 4 or 2 channels instead of 8 on each muxed lines increment and manage the data position in the array. It's possible but I did not I don't use the AINSER module, I re-write an adapted one in the app directly, It let the AINSER module available for other features.

     

    1 hour ago, Zam said:

    Color TFT is so great, how this is handled ? I suppose there is massive special driver for it...

    Yes it's a special driver but I write it as an app_lcd module this can be reuse for other app, the MIOS32_LCD and GLCD functions continue to work if you correctly set the back and fore colors, but some direct APP_LCD_xxx functions were added for specific pixel depth.

    1 hour ago, Zam said:

    Anyway I'll have a look when code available

    I will make this code available on next commit, It's also a good practice for me to work on a personal repo before working on the MCAN branch of the official MIOS32 repo.

    Best
    Bruno

  10. The HAARP, a Hardware Advanced Arpeggiator.

    in MIDIbox User Projects

    Posted

    1 hour ago, Hawkeye said:

    Hope you are not mad, if I also implement a few (not all!) of the arp functions on the LoopA arp - but yours will be first, over here still working on it! ;-)

    Hi Peter,

    There is really no problem. LOOPA and HAARP are more complementary than competitive.
    Both are "real time" oriented but have different use and operation.

    (I do not remember if you implemented the "Force To Scale" if it's not the case, it can be a good feature on your machine too.)

    Internally their process structure are very different, but if you want to know how I coded some parameters, tell me if I can 'help', even if I feel pretentious to say that to someone who codes better than me.
    There is no competing here, the important thing is to give life to all that and share it.

    But for sure, it's better if our machines or modules can be complementary.
    I also look forward to the @Phatline's CC-Looper, here again we are in the complementary.

    Best regards
    Bruno
     

  11. The HAARP, a Hardware Advanced Arpeggiator.

    in MIDIbox User Projects

    Posted · Edited by Antichambre

    Hello,

    This is an introduction for my new baby, a really funny toy, the HAARP (yes I like conspiracy theory ;)


    IMG_0302.jpeg?raw=1


    It's a pure MIDIbox Project, just a dedicated CS and some coding. It works with any STM32F4 Core.

    IMG_0292.jpeg?raw=1IMG_0293.jpeg?raw=1
     

    Why? Many synths have an integrated arpeggiator, the SH-101 is well known for that, but the available parameters are still limited. There is also some good plug-in I think especially of the Ableton live's one but it's software.

    So I designed an hardware one, "LIVE" oriented, starting from the @TK.'s arp example. No encoder(except for MENU section Data entry), all parameters are directly accessible and are potentiometers. The screen is a small color TFT with a resolution of 128x160(sorry for picture, colors are better in real).

    It's 8 independent voices. 8 banks of 8 Presets. Session are saved/loaded from the SD Card.
    1905_mb-haarp_euro_v1b_6_06.png?raw=1
    The Arpeggio parameters are divided in 3 sections:
    First is the TIMING Section (Purple pots):

    • On/Off button,
    • HOLD Button, it holds or releases the Notes in the notestack.
    • The MODE Pot, it's UP, DOWN, UP-DOWN and AS-PLAYED, fr the moment but I will implement more.
    • The RATE, from slowest to fastest, from 4 Bar to 32nd with dotted and Triplet value.
    • The RESYNC, it retriggers the arpeggio, values are the same as RATE parameter.
    • The OFFSET, it will shift left or right the starting step(note). Is Note Stack and MODE dependent.
    • The DELAY, it will delay the whole arpeggio within the step range(duration), is RATE dependent.
    • The GATE, the length of the Note, max is STEP length, is RATE dependent.
    • The SHUFFLE, it will delay all the odd steps, in the range of an half step, is RATE dependent.

    Second is the TRANSPOSITION Section (Yellow, Orange, Red):

    • Simple Transposition On/Off (Yellow).
    • Simple OCTave Transposition, +/- 10.
    • Simple SEMItone Transposition, +/-12
    • Repeat On/Off.
    • Repeat, LOOPS number, 1 to 8.
    • Repeat, SHIFTing on each loop, +/-32 semitones.
    • Force to Scale On/Off
    • Force To Scale, SCALE, list is the same as the Force to Scale example from the repo.
    • Force To Scale, ROOT from C to B semitone.

    Third is the VELOCITY Section.

    • REGEN Pre/Post(Target process) button.
    • REGEN, +/- 100%
    • Target process On/Off.
    • TIME, the time to reach the target value, in PRE initial value is the regenerated value. in POST initial value is the one stored in the Note Stack.
    • TARGET is the targetted value, 0 to 127.
    • RETRIG, if on the TIME is retriggered by the RESYNC parameter.

     

    The main page of the screen represents an octave range, the note color changes depending on the octave, there's a Velocity section on the bottom, it's like a piano-roll.
    In the code, the arpeggio processing is ready, it remains me to complete the MENU section, I was waiting for the CS PCB to write it, now I can... ;)
     

    This little guy is to much fun, so I can't keep it for me. Then i will propose it to you ASAP. and I hope it will help me to finance some other bigger projects I've got in my back-pocket ;)
    I will try to make it available in two format, I'm currently working on a PCB for USB host/device, sdCard MIDI etc.. which will fit for both version and will be reuse for other small toys like that.

    1. An Eurorack version for the patching addicts. I used a MCP3204(4 channels) instead of a MCP3208(8 channels) for the AINSER, it's an AINSER32. I use only 2 channels for the 16 pots(8Multiplexed lines * 2 channels), it remains 16 analog Inputs which are accessible to connect some CV In Modules, thanks to @Hawkeye for making me think about this.
      The SRIO Chain is available too, you can connect GATE In (DIN) easily.
      You will be able to connect the MIDIPHY CV/GATE Out Modules which will be available soon. @latigid on is working on it.
      MCAN will be available, for an internal MIDI bus within your Eurorack, I reuse the BUS1 and 2 from the Euro Power connector for that purpose.

      1905_mb-haarp_euro_v1b_4_02.png?raw=1

       
    2. A Desktop version, for MIDI purpose only(except if i find a way to add some CV/Gate without designing a too much big box).

     

    Voilà! More information will be available soon.
    For the moment this is a small video I made, I seem a little febrile but it's because I continue to discover it every day.
     


    I really love this little toy, it is very effective and musical, even in LIVE and if the Force To Scale is activated, there's no wrong note ;)

    Best regards
    Bruno



     

    • Like 1

  12. AINSER sampling rate

    in MIDIbox NG

    Posted

    1 minute ago, Zam said:

    meaning mios can handle at least 125uS scan

    You can try to call the AINSER_Handler with a Timer set at the desired rate,but usually a freertos task is used to call it, and its minimum period is 1ms( 1 / portTICK_RATE_MS )

    Check tutorial#012b_ainser_muxed: 

    /////////////////////////////////////////////////////////////////////////////
// This hook is called when an AINSER pot has been moved
/////////////////////////////////////////////////////////////////////////////
static void APP_AINSER_NotifyChange(u32 module, u32 pin, u32 pin_value)
{
  // toggle Status LED on each AIN value change
  MIOS32_BOARD_LED_Set(0x0001, ~MIOS32_BOARD_LED_Get());

  // convert 12bit value to 7bit value
  u8 value_7bit = pin_value >> 5;

  // send MIDI event
  MIOS32_MIDI_SendCC(DEFAULT, Chn1, pin + 0x10, value_7bit);
}


/////////////////////////////////////////////////////////////////////////////
// This task scans AINSER pins and checks for updates
/////////////////////////////////////////////////////////////////////////////
static void TASK_AINSER_Scan(void *pvParameters)
{
  portTickType xLastExecutionTime;

  // Initialise the xLastExecutionTime variable on task entry
  xLastExecutionTime = xTaskGetTickCount();

  while( 1 ) {
    vTaskDelayUntil(&xLastExecutionTime, 1 / portTICK_RATE_MS);

    // scan pins
    AINSER_Handler(APP_AINSER_NotifyChange);
  }
}

     

  13. AINSER sampling rate

    in MIDIbox NG

    Posted

    23 minutes ago, Zam said:

    what is the AINSER sapling rate

    The AINSER is usually called every ms, but! if you are using the 64 version, it's one multiplexed line every ms then scanning the 64 inputs takes 8ms.

     

    27 minutes ago, Zam said:

    also what is the round trip from AIN to AOUT if I want to process something in between (like midi or NG conditional)

    This is something easy to do in a regular App, using the AINSER_Handler, but in NG I don't know.

    Best
    Bruno

  17. MCAN

    in MIDIbox NG

    Posted

    22 hours ago, TK. said:

    Which values would you like to permanently store & change in the bootloader.

    I need names + sizes

    I will define those values in mios32_sys.h within the MIOS32_SYS_ADDR_BSL_INFO_BEGIN section
    -> https://github.com/midibox/mios32/blob/master/include/mios32/mios32_sys.h

    As you can see, we can either define a block + confirmation value, or individual values + confirm.
    If you could predict today how many bytes need to be allocated, we could use a single confirmation which saves space for other future extensions (used for other purposes)

    Best Regards, Thorsten.

    Hi Thorsten,

    For the basic mode nothing more than the node number is necessary. It's 3 bits (0...7) then 1 byte is enough
    Something like this: 

    # define MIOS32_SYS_ADDR_DEVICE_ID_CONFIRM  (MIOS32_SYS_ADDR_BSL_INFO_BEGIN+0xd0) // 0x42 to confirm value
# define MIOS32_SYS_ADDR_DEVICE_ID          (MIOS32_SYS_ADDR_BSL_INFO_BEGIN+0xd1)
# define MIOS32_SYS_ADDR_FASTBOOT_CONFIRM   (MIOS32_SYS_ADDR_BSL_INFO_BEGIN+0xd2) // 0x42 to confirm value
# define MIOS32_SYS_ADDR_FASTBOOT           (MIOS32_SYS_ADDR_BSL_INFO_BEGIN+0xd3)
# define MIOS32_SYS_ADDR_SINGLE_USB_CONFIRM (MIOS32_SYS_ADDR_BSL_INFO_BEGIN+0xd4) // 0x42 to confirm value
# define MIOS32_SYS_ADDR_SINGLE_USB         (MIOS32_SYS_ADDR_BSL_INFO_BEGIN+0xd5)
# define MIOS32_SYS_ADDR_ENFORCE_USB_DEVICE_CONFIRM (MIOS32_SYS_ADDR_BSL_INFO_BEGIN+0xd6) // 0x42 to confirm value
# define MIOS32_SYS_ADDR_ENFORCE_USB_DEVICE (MIOS32_SYS_ADDR_BSL_INFO_BEGIN+0xd7)
# define MIOS32_SYS_ADDR_SPI_MIDI_CONFIRM   (MIOS32_SYS_ADDR_BSL_INFO_BEGIN+0xd8) // 0x42 to confirm value
# define MIOS32_SYS_ADDR_SPI_MIDI (MIOS32_SYS_ADDR_BSL_INFO_BEGIN+0xd9)
# define MIOS32_SYS_ADDR_MCAN_NODE_CONFIRM   (MIOS32_SYS_ADDR_BSL_INFO_BEGIN+0xda) // 0x42 to confirm value
# define MIOS32_SYS_ADDR_MCAN_NODE (MIOS32_SYS_ADDR_BSL_INFO_BEGIN+0xdb)

    Let me 1 day or 2 and I will do the stuff for the Bootloader Updater, as you get the minimum to do, just valid/correct.
    Except if you really want to do it yourself.

    Best regards
    Bruno
     

  18. Why does the HC165 even work?

    in Design Concepts

    Posted · Edited by Antichambre
    encoder note

    9 minutes ago, FantomXR said:

    Yes. But I could use LV165 or not? That could be supplied with 3V3.

    Yes of course, just check the levels from the datasheet.
    Just take care if you use encoders, for example I never tried a pec16 with a 3V3 voltage and they are given for 5V.

  19. Why does the HC165 even work?

    in Design Concepts

    Posted · Edited by Antichambre

    DIN and DOUT modules were made a long time ago with HC, more than that with HC and 541(forJ8/9 andJ19) DIN/DOUT modules stay compatibles to all SPI ports. J8/9 J19 and J16 included.
    HCT version are only 5V(Supply voltage) and J16 is a 3.3V SPI port.
    But you can use HCT595/165 and remove the 541 on your own design. Keep in mind HCT need 5V supply voltage.

  20. MCAN

    in MIDIbox NG

    Posted

    1 hour ago, TK. said:

    We could reserve a bootloader location to make this basic_node number configurable without touching the source code.

    it would be great! :)
    ...
    I will definitely go in this direction.
    Thank you for your answer

    Best regards
    Bruno

  21. JU60

    in MIDIfication

    Posted · Edited by Antichambre

    @Zam
    I just restore then mod a juno 60 for a friend using the juno-66 from tubbutec, it works great!
    The only critic is that they provide not enough length cable, I was obliged to change them to follow the existing cabling path, I did not change the MIDI I/O cable then cable is straight from cpu to old DCB position(not very good too).
    But this mod is great and add a lot of features to the juno-60 I highly recommend it to you, do not reinvent the wheel, they made it very well.

    IMG_0181.jpeg?raw=1

    IMG_0186.jpeg?raw=1

    IMG_0188.jpeg?raw=1

    IMG_0185.jpeg?raw=1

    IMG_0189.jpeg?raw=1

    Best regards
    Bruno

  22. MCAN

    in MIDIbox NG

    Posted · Edited by Antichambre

    On 1/8/2019 at 0:26 PM, Antichambre said:
    On 1/7/2019 at 10:41 PM, TK. said:

    how to you handle collisions?
    If two cores send a frame with the same ID concurrently, the arbitration will pass and the remaining frame might collide (e.g. due to different data being sent).
    The CAN nodes won't automatically re-send the frames.
    This situation could be avoided if you ensure that each core sends unique IDs, e.g. bring source and destination node into the ID.
    I guess that you considered this for extended frames, but this format isn't enabled by default... you should do this.

    I don't manage collisions in basic mode, it was the case before but after some tests I removed it cause it was working fine, for a basic mode. Errors happens only when the traffic begins to be very dense.
    On error It doesn't stop or isolate the node I just loose some frame. It's a choice for this mode. Very short frames but collision are not handled.
    In enhanced Mode the Extended Id is used there's no problem.
    But I will do if you think it's a bad idea to let it like that, for that I've got 2 choices:

    • Using the extended Id for basic mode too.
    • I can add 3 bits for node signature in the standard id and limit the basic mode to 8 nodes maximum. 
    
  struct {
    // extended
    u32 none:1;
    u32 is_request:1;
    u32 is_extended:1;
    u32 src_node:7;
    u32 dst_node:8;
    u32 app_type:3;
    // standard
    u32 cable:4;
    u32 type:4;
    u32 vman_prio:3;
    // ports
    u8  src_port;
    u8  dst_port;
  };
} mios32_mcan_header_t;

    I can shift vman_prio field after type and cable and use it for a 3 bits limited Id.

    I decided to add a Basic Id field, 3 bits which will allow 8 Cores on the MCAN Bus. And remove the vman_prio field which was an optional feature.
    I think it's the best compromise.
      

      struct {
    // extended
    u32 none:1;
    u32 is_request:1;
    u32 is_extended:1;
    u32 src_node:7;
    u32 dst_node:8;
    u32 app_type:3;
    // standard
    u32 basic_node:3;
    u32 cable:4;
    u32 type:4;
    // ports
    u8  src_port;
    u8  dst_port;
  };
} mios32_mcan_header_t;

    - Message types are always prioritized(type)
    - We keep the 16 MCAN ports (cable)
    - 8 chained cores max in the basic mode(basic_id), the basic_node field will not be used in extended mode and replaced by the src_node.
    Of course this basic_node id will have to be declared in mios32_config.h and different for each core on the buss, value from 0 to 7.
    Notes: the type of message is always a priority, the cable has priority over the id

    @TK. What do you think about?

    Best regards
    Bruno

  25. midiphy SEQ v4+

    in MIDIbox SEQ

    Posted

    39 minutes ago, Hawkeye said:

    PS: @latigid on is so busy designing new stuff, that he had no time to claim his serial number yet, maybe we should assign him serial number #1.5 as he did most work on this project!

    You can give him the number #0 not as a null one but as the origin, the source, the root, the base one!

×
×
  • Create New...