Jump to content

Rio

Members
  • Posts

    727
  • Joined

  • Last visited

  • Days Won

    9

Posts posted by Rio

  1. you can of course fit it with heatsinks, but it's not necessary. It is normal for the 6581 to get warm/hot, but it is also in their nature to run at such temperatures. if i read it correctly, then there are only 8580 in use and there also a fan installed. I've never had to worry about anything like that (fan/cooler), nor have I ever had any problems during operation. they break when handled incorrectly (ESD).

    Note the fact that a heatsink, fan or whatever you use is fine, but that is never installed inside an original c64.

    ... and yes, your device does look cool.

  2. Maybe someone is interested in the latest binaries & sources.

     

    Current MacOS binaries can be found here (Sidplay5 adaption):

    https://github.com/Alexco500/sidplay5/releases/tag/v5.1.0_111

    ..so no one has to go through the agony of xcode compiling/signing ;)

     

    and for Windows (32Bit/64Bit) you can find the binaries for Vice 3.2 with ASID (based on aTc's code) here:

    https://sourceforge.net/projects/vice-emu/files/misc/WinVICE-3.2-asid/

     

    Have a nice day!

  3. Yes, clock stretching slows down the clock line for I2C communication. Some of the boards I use with I2C do not work because the clock rate is too high. With clock stretching it works but I don't know how high the clock rate is. But it must be below 400 kHz (this is the limit that is noted in the specifications of one of my external hardware). 

    For SPI communication, one of my boards is limited to 1Mhz. So it would be good to know some specifications about the core8 board. 

  4. And if you go back to 4.096? Does it work then? Plug the SD card out and then in. Maybe the contacts for your setup on SD are just a bit morbid over the time, but the app would normally have informed you about this. And If 4.096 works, check out the changelog for the last version.

  5. I also use an LPC17. Maybe I can help you. My SEQv4 has been running fine for years (decades) with 12 midi outputs. I need more details on what you have configured in your app? Are all the other messages to your midi ports working (NOTE ON/OFF etc. and is it CC related only)? 

    Which midi ports have you connected and how?

  6. Simple questions for the core v3 /PIC18F board using MIOS8:

    1. How fast is the SC line for both modes (MIOS_IIC_CtrlSet [0 default / 1 clock stretching]) ? and is it <400KHz? Because one of my external boards as an IIC slave only accepts a clock up to 400KHz and it does not react as it should ATM.

    It seems that I get an ACK back to the PIC18F master in clock stretching mode, but the external device itself remains without any functionality. If I try it without clock stretching, the watchdog restarts the PIC18F master app because it does not receive an ACK in the loop and the loop probably runs too long for that.

    BTW: the external board can be well controlled by an Arduino using the standard frequency of 100Khz defined in the wire/twi classes of the Arduino core library:https://github.com/arduino/ArduinoCore-avr/blob/master/libraries/Wire/src/utility/twi.h#L30

    But of course I don't want to control it with an Arduino, but with my PIC18F with MIOS8!

     

    2. I would also be interested to know how fast the SPI clock is - because for a special application it has to be <1Mhz.

  7. Hi,

    I want to use clock stretching, so I had read about:

    http://www.ucapps.de/cmios8_fun.html#MIOS_IIC_CtrlSet

    MIOS_IIC_CtrlSet notes to add a 1k pull-up resistor to the SCL line (Pin #22 of the PIC). Required for use? If I take a look at:

    http://www.ucapps.de/mbhp/mbhp_core_v3.pdf

    there is already a 1k resistor to +5V on J4 (SC line) Pin 6.

    Is it the same resistor that was named here?

    Greetings,

    rio

     

  8. On 5/18/2024 at 8:49 AM, Rio said:

    I can try to compile it according to your description...

    I am quoting myself, but just to confirm that it is possible to compile & run on a Mac M2. Thank you for the concise instructions two answers ago.

    However, there are a few visual glitches and a few crashes (but unrelated for working playback), probably due to using outdated classes.

    Crashes occur with sidplay by midi device list detection due to previously connected midi device, by window resizing and sometimes midipatch bay crashes when exiting.

  9. Are you looking for CEM 3387 or CEM 3378? Both differ in certain functionality. 

    Yes, it is rare, but not impossible to get. Wait and watch on ebay or second hand sellers, etc. the price should be double (or even higher) what it was 20 years ago. e.g. the cem3378 were rare even then.

    I got mine (3378) around ~2006 for 20 euros each. But those were already the last in stock. 

    Greetings,

    rio

  10. Do you have experience in programming? The reason I ask is because it requires that. And your approach of changing the args of a core function is definitely not the right way.

    Btw: I think this is pretty custom for your needs, since the mute works in a different way in the midi implementation (regarding tracks).

    Otherwise, if you absolutely need it and above all if you are confident that you can do it, then you can hack the seqv4 source and define and include your own external control as a CC and specify & transmit the channel there as a value, which is used in your own loop through the tracks and mutes or unmutes the corresponding tracks if (value == track's channel).

    e.g.

    seq_midi_in.h -->
     

    #define SEQ_MIDI_IN_EXT_CTRL_MUTE_BY_CHANNEL 16
    
    #define SEQ_MIDI_IN_EXT_CTRL_NUM_IX_CC     17

    <-- (make sure to increase the NUM_IX_CC)

     

    seq_midi_in.c -->

    seq_midi_in_ext_ctrl_asg[SEQ_MIDI_IN_EXT_CTRL_MUTE_BY_CHANNEL] = 122; // your cc for that control


     

    const char* ext_ctrl_str[SEQ_MIDI_IN_EXT_CTRL_NUM] = {
    
    ..
    
    "Mute by channel", // your name for that control
    
    }

    <-- (index 16 must be noted here)

     

    append your external control handling inside:

    static s32 SEQ_MIDI_IN_Receive_ExtCtrlCC(u8 cc, u8 value)

    if (cc == seq_midi_in_ext_ctrl_asg[SEQ_MIDI_IN_EXT_CTRL_MUTE_BY_CHANNEL]) { ... }

     

    but i think if you want to change something in the code, you have to get familiar with the structure of the entire source anyway.

     

    Greetings,rio

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

     

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

  13. Quote

    5. This finally showed up the bootloaders details vrsion, board etc in theLEFT hand box below the input dropdown..

    fine

    Quote

     

    13. I powered off the midibox once completed and changed to powering it via the wall plug rather than my laptop  and lo

    my new session (named "apple") was now the active session upon startup and it SOULD be read to / saved to etc.

     

    If you end up uploading the Midibox SEQ app via midi, you should be able to manage sessions from the midibox options menu. You do not need to make sessions via the terminal - but it is possible.

    If you have the feeling that something in your 'old' session is stored incorrectly or is corrupt, then you can also try to load this session and copy certain things (patterns etc.) into your new (cleanly created) session - all this directly on the unit. And maybe in future just make a backup of the SD more often. no corrupt files have happened to me in all that time, but I always make chronological backups on the PC.

    Quote

    12. I then created a brang new Session via the MIOS terminal ..this took quite an unexpected long while....all the time I had two progress bars on the screen of my midi box, it may have taken around five minutes to complete...I just let it run

    That's tooo long! So my suggestion: please test a new SD Card <= 4GB! I also had problems in the past with SD cards of different types.

    Maybe my old thread helps out (but note, I use a LPC17 core - but the conclusion is to use a smaller SD card, which I have already mentioned):

    Perhaps as a tip for the future: I can't say anything about the hardware problems, but you should also check all the connections to the SD card - in case you soldered together your own SD card board (or the previous owner). Otherwise, test another SD card).

     

×
×
  • Create New...