Antichambre

This has to be done in the bootloader not in the app. upload the right hex file from http://ucapps.de/mios32/mios32_bootloader_v1_018.zip then set your lcd_type then re-upload your app. Have fun ! Bruno

Merry Christmas and Happy New Year to all !!!

I'm surprised cause I did it for the HAARP and use a 4 channel ADC to reduce the cost. But I use it on the regular J19. Channels are reversed like you. I don't use the AINSER64 module and add/rewrite a simplified/dedicated copy in the app folder. I made some changes to reduce the scanning and make it faster. The CS uses only 16 inputs, the 16 others are for a future extension like CV in. And it works for me. s32 ARP_AIN_POT_Handler(void (*_callback)(u32 pot, u32 value)) { // the mux_ctr -> pin mappin is layout dependend const u8 mux_pin_map[8] = {0, 1, 2, 3, 4, 5, 6, 7}; static u8 mux_ctr = 0; // will be incremented on each update to select the next AIN pin static u8 first_scan_done = 0; static u16 link_status_ctr = 0; s32 status = 0; // init SPI port for fast frequency access // we will do this here, so that other handlers (e.g. AOUT) could use SPI in different modes // Maxmimum allowed SCLK is 2 MHz according to datasheet // We select prescaler 64 @120 MHz (-> ca. 500 nS period) status |= MIOS32_SPI_TransferModeInit(ARP_AIN_SPI, MIOS32_SPI_MODE_CLK0_PHASE0, MIOS32_SPI_PRESCALER_64); // determine next MUX selection int next_mux_ctr = (mux_ctr + 1) % 8; // loop over channels int chn; for(chn=0; chn<2; ++chn) { // CS=0 status |= MIOS32_SPI_RC_PinSet(ARP_AIN_SPI, ARP_AIN_SPI_RC_PIN, 0); // retrieve conversion values // shift in start bit + SGL + MSB of channel selection, shift out dummy byte MIOS32_SPI_TransferByte(ARP_AIN_SPI, 0x06 | (chn>>2)); // shift in remaining 2 bits of channel selection, shift out MSBs of conversion value u8 b1 = MIOS32_SPI_TransferByte(ARP_AIN_SPI, chn << 6); // shift in mux_ctr + "Link LED" status to 74HC595, shift out LSBs of conversion value //u8 b2 = MIOS32_SPI_TransferByte(ARP_AIN_SPI, ((chn == (ARP_AIN_NUM_CHANNELS-1) ? next_mux_ctr : mux_ctr) << 5) | link_status); u8 b2 = MIOS32_SPI_TransferByte(ARP_AIN_SPI, (chn == 1 ? next_mux_ctr : mux_ctr) << 5); // CS=1 (the rising edge will update the 74HC595) MIOS32_SPI_RC_PinSet(ARP_AIN_SPI, ARP_AIN_SPI_RC_PIN, 1); // store conversion value if difference to old value is outside the deadband u16 pot = mux_pin_map[mux_ctr] + 8*chn; // the mux/chn -> pin mapping is layout dependend u16 value = (b2 | (b1 << 8)) & 0xfff; previous_arp_ain_pot_values = arp_ain_pot_values[pot]; int diff = value - previous_arp_ain_pot_values; int abs_diff = (diff > 0 ) ? diff : -diff; if( !first_scan_done || abs_diff > ARP_AIN_POT_DEADBAND ) { arp_ain_pot_values[pot] = value; // notify callback function // check pin number as well... just to ensure if( first_scan_done && _callback && pot < 16 ) _callback(pot, value); } } // select MUX input mux_ctr = next_mux_ctr; // one complete scan done? if( next_mux_ctr == 0 ) first_scan_done = 1; return 0; // no error } For your layout: You can change the MUXes mapping here: // the mux_ctr -> pin mappin is layout dependend //const u8 mux_pin_map[8] = {0, 1, 2, 3, 4, 5, 6, 7 }; //const u8 mux_pin_map[8] = {1, 4, 3, 5, 2, 7, 0, 6 }; // reversed pins const u8 mux_pin_map[8] = {6, 3, 4, 2, 5, 0, 7, 1 }; // order of MUX channels You can reduce the channels: for(chn=0; chn<3; ++chn) { u8 b2 = MIOS32_SPI_TransferByte(AINSER_SPI, ((chn == 2 ? next_mux_ctr : mux_ctr) << 5) | link_status); And limits the number of inputs by security: if( first_scan_done && _callback && pin < 24 )

Ahah! Clever!

No, this is not the issue. Did you try the tutorial 012b? To test your AIN module alone. Best, Bruno

So you've got a custom AINSER64 with 3 MUX only and you use only 3 channels of the ADC. Your issue is very strange. It can't be inhibit pin issue cause inhibit switches off all multiplexed inputs. It can't be the ADC cause you receive something from third channel. ABC lines are the same for all MUX, so there's no short-circuit, cause only one MUX doesn't work. Just in case, is there continuity between all "A" pins, "B" and "C" of the MUXes? But I'm pretty sure you already checked it. It's not a faulty MUX cause you swapped them. Hummm... When you say: Does it means the AIN hook is called 8 times when the only working knob is moved?

Wood Side Story. ;) Tomorrow is sanding time...

I already have 5 pairs to make and this last call ! ;) Closed ! Best Bruno

Yes you already own a small keyboard if I remember well. ;)

Thorsten, Have a look at this: https://www.synthtopia.com/content/2019/12/16/cme-debuts-widi-master-a-wireless-midi-over-bluetooth-adapter/ Best regards Bruno

It seems bottom of the metal enclosure will be blue ;)

Hi Thorsten, Is it possible to do not pair the two devices and create a network with it? If a device can broadcast to several others devices and also receive(merge) from them too? Is there a kind of receiving state or meter, to be able to manage the distance between the devices? Best Bruno

Capabilities and inside features are awesome!.. 512k RAM :-) hummm Do you think you will be able to find the time, during this harsh winter, to migrate the mios32 bootloader to the HAL( F4 ;), so that this magnificent OS that we love so much will become almost eternal? Hihi In any case thank you and have good time with DIY and experimentation... So good to read that! :)

Hello! @lp1977 asked me some wood sides for the SeqV4+, the exact ones I made for mine except that oak will be used, no more exotic wood. it's a little stupid to turn on and prepare the machine for just a pair. I provide the pair sanded but raw, for you to choose and apply the finishing you prefer. I will add some longer screws in the package. PM me if interested. Best regards Bruno

Always about the RSF, there was already an OFFSET Pot which shift the notes over the timeline, it moves all the notes in the range of +/- the arpeggio length minus 1. It changes the starting Note. So I added an option for the RSF which is "RSF follows OFFSET". When enabled the RSF becomes relative to the OFFSET, it moves with the notes on OFFSET changes and each note value keeps its resting state , disabled the RSF is static and resting steps always the same independently from the OFFSET and it's not always the same notes which are off. Maybe not clear but video will explain all that better ;) Best regards Bruno

Yes but I left the country, I've got the HAARP with me to work on at night but I'm somewhere in an hotel in Africa, connection is not good. So when I will be back home...

Done! // Voice Structure typedef union { struct { u8 ALL[1+(sizeof(notestack_item_t)*ARP_NOTESTACK_SIZE)+8+1+7+6+3]; }; struct { u8 notestack_len; notestack_item_t notestack_items[ARP_NOTESTACK_SIZE]; u32 resting_steps[2]; // Resting Step Feature(RSF) requested by FlavioB ;) arp_par_func_t func; arp_par_timing_t arp; arp_par_trans_t trans; arp_par_vel_t vel; }; } arp_voice_t; Then this is how it works: The selected step for Resting Step Feature(RSF) is the one with grey background, you can move this selection with the encoder. (Initially the encoder was used for TEMPO, but tempo is the altered function of the encoder now(with ALT button), and RSF is the main function of the encoder) Pushing the encoder(switch) is toggling the RSF for the selected step. then a white bar appears at the bottom of the velocity and the semitone becomes grey. HOME button + Encoder Switch is clearing all the Resting Steps. Note: If an HID keyboard is connected: Left/Right Arrow for selection. Up/Down Arrow or Enter for Toggling Del/BackSpace to Clear All ... And this is not a legend, it already works ;) Voilà! PS: Shooting a picture of a TFT with an iPhone is a bad thing ;) Colors are really better in real :) Best regards Bruno

It's a VGT6.

I think I understood how it works, in my case it's worst than I thought this needs more than 32 muting bits. A u32 word is not enough. If notestack(10notes) is fully filled and the motif is a PINKY UP&DOWN or THUMB UP&DOWN the sequence achieves 36 steps for example... I added 2 u32 words for each voice, it's a 27Kbytes session now instead of 23, and it's fine even with the bitmaps of the TFT which are rather greedy ;) I think I will not add it as a list like the notestack EDIT but directly in the HOME page(piano-roll) it will avoid me to modify the process, no need of pre-calculation of the whole sequence. In fact thank you, it will be a great feature... And there will be a "Resting Steps feature requested by FlavioB" somewhere in the code ;) Best regards Bruno

Cause the led is static and only the cap moves, I thought a too much large led might perturb the cap travel, and never tried it. Great!! ;) I also put a red one for REC button :) Congratulations! Enjoy! And Welcome cause it seems to be your first post! ;)

I had a look, have to test it. It's easy to implement it on the harpie cause there's no preset, the thing you dislike on it. On the HAARP a full session is loaded in RAM, to permit the user to work on the whole session in a non-destructive fashion. If I add this feature I have to add a 32bit word to each voice(8x8x8) in the structure as we can save it or it has no sense to add it, it's 2K to find in ram just for this. More than that it obliges me rethink a part of the processing. So if I do it, I've got to do it now, to choose now, this is not something I will be able to add later, and it needs to change the structure of the session, means old presets you made without will be not compatible anymore if I add it later(Except if I implement a versioning and translating process :( huge) I will try and spend some time for that, even if it delays the first release. Under construction note stack editor ;) Best regards

Peter, BRAVO!!! It's a beautiful thing, looking forward to seeing the metal case, it will be awesome. It remains me some from the SeqV4+ Custom Keycaps I made, not enough for a SeqV4+ set, but enough for LoopA. for free just pay shipment if interested. Best regards Bruno

I will not argue eternally, you have accused me of false insinuations so I defended myself and in PM to do not annoy people. I just give a hand that you spit on. You just confirm. By the way, you're right, Emilie shares everything. Oh! And I am also on the MI forum Ahhhhhhhhhhhhhhhhhh lol

You don't need to justify cause it wasn't an accusation but the explanation why we prefer to protect it. So there was no insinuation like you said. There was nothing against you especially and personally. I just asked you to be quiet and do not react like that in PM to avoid the last exchanges that we have just had here, cause people don't care. In the same message I also explained you why Midiphy, "people don't have time to start from scratch" "Midiphy is just a slight declination of TK's work" etc... Exactly what Peter told you at the same time here. Do not give up like that, there's everything you need here, start speaking technical and I'll be one of the first to help you in your project, as usual. Sincerely, Bruno