• dfkettle

    @seb-harmonik.ar For now, I don't need to cross-compile. And even if some day I do decide to share on Github or whatever, I don't really feel comfortable releasing something for all platforms if I'm unable to test it myself. But I guess most people are faced with the same problem, unless they have access to machines running all three OS's.

    posted in extra~ read more
  • dfkettle

    Which toolset is recommended for compiling externals under Windows? Or will any of the following work equally well?

    1. Mingw
    2. Msys
    3. Cygwin
    4. Visual Studio

    For now, I'm not thinking of sharing any externals, since I'm just learning how to write them, plus I don't have access to a Mac, and the only Linux system I have is a Raspberry Pi. So I don't need to worry about cross-compiling.

    Thanks.

    posted in extra~ read more
  • dfkettle

    @whale-av said:

    @dfkettle So you have the Martin Peach 2018 files through Deken.

    Yes, I installed it through Deken. Isn't that the latest version?

    Martin had mentioned the meta messages on the list though, and they are in the 2018 help file.

    I haven't tried any of the meta messages yet, although I'm going to eventually. I'm just using [track n( messages to set the track no.

    I have played a little with them this afternoon and have not so far been able to ascertain what exactly is required but....... I did get multiple tracks, although they are not named.
    Open the .mid file
    Then send into [midifile] [meta 0 678( ...... could maybe be [meta 0 0(......??
    Then [meta 0 679( ...... again, could be [meta 0 1( ......?
    Then [meta 3 woof( .........or whatever name you want but it doesn't seem to give a name.
    Then [meta 3 lala( ...... same as above)
    Then start recording and send [track 0( and send in some notes.
    Then send [track 1( and some notes.

    That gave me 2 tracks but a load of "no running status" messages
    I haven't tried the other [meta f s( messages yet.

    I think I asked earlier, but is anyone maintaining his code? Is there a github repository where I can ask questions?

    Alternatively, is there any other external that I could use instead of Cyclone or MrPeach to record and save MIDI data? I've reverted to using Cyclone for now, but it seems to me that the last MIDI event sometimes gets dropped in the saved file. There's no "flush" function in [cyclone/seq], afaik. Is it possible that all the data isn't getting written to the file?

    posted in technical issues read more
  • dfkettle

    @dfkettle I would expect read/write to be first as they get the file/set the header for writing (MThd).
    Then the track.... as that means moving on within the file to the next header for a read, or writing a Track header for a write (MTrk).

    That's the order I tried first, but it didn't seem to work. Anyway, I changed it back again to agree with what you suggest, but it still seems to disregard the track number (it plays the track even though I specified track 0 when writing and track 1 when reading. Here's the latest version:

    test-midi-mrpeach.pd

    Image1.jpg

    P.S. What does your midifile-help file look like?...... is it this one from 2010?
    So for a write the track would go between "1" and "2".

    Essentially, although it says "Martin Peach, 2010 - 2018" on mine. However, I'm wondering now how I would create a file with more than one track, if you have to specify the track number between steps "1" and "2". (in other words, before you start recording). Can you change the track number after you've started recording? How could you create two tracks that play at the same time? Maybe that isn't even supported by this library.

    EDIT: Does the 'flush' message close the file after writing? I don't see anything in the help file about a 'close' message, so I'm assuming it does.

    posted in technical issues read more
  • dfkettle

    Up until now, I've been using [cyclone/seq], [cyclone/midiformat] and [cyclone/midiparse] to read and write MIDI files. They're simple to use, but don't support as many features as [mrpeach/midifile], it seems to me. However, I'm struggling to understand the documentation in the help file. There are lots of examples of the different messages you can send to [midifile], but it isn't always clear in what order they should be sent (btw, I have that complaint about a lot of help files, not just this one). I think that might be the cause of this problem, but I'm not sure. I'm writing to track 0 (I think), but when I read the file, it seems to play all tracks, regardless of which one I specify. The documentation states that you should specify -1 to play back all tracks. But it seems to be doing that anyway, even though I specified track 1 when reading. I think the problem may be that I'm not sending the messages in the correct order.

    I understand that the original developer, Martin Peach, passed away a couple of years ago. Is anyone currently maintaining this external?

    test-midi-mrpeach.pd

    Image1.jpg

    posted in technical issues read more
  • dfkettle

    @ddw_music Thanks. I found other posts about stack overflows that suggested adding a [delay], but didn't understand why that would make any difference. I'm familiar with the idea of a stack (I'm a retired programmer), but didn't realize that Pd worked that way, I thought it was a simple loop, not recursive.

    posted in technical issues read more
  • dfkettle

    @oid Well, I found the problem and it really didn't have anything to do with my [tgl2] abstraction. It was higher up in the call hierarchy, in an abstraction that reads data from a text file to load into the toggles. As long as I had a small number of toggles (and therefore a small number of lines in the text file), it worked. But if I had too many (I'm not sure how many is too many), I started to get stack overflow errors.

    To fix it, I added an [until] object to the abstraction that loads the data. I'm still not sure why the original version doesn't work, though. They both send bangs to the [textfile] object to read the next line, and stop when the last line is read. A timing issue maybe?

    The old version:

    Image1.jpg

    The new, improved version:

    Image2.jpg

    posted in technical issues read more
  • dfkettle

    Thanks. I've never used [trace] before, I'll read up on it. I guess there's no way to print out a stack trace, like in other languages such as C? Maybe some undocumented startup flag or something?

    posted in technical issues read more
  • dfkettle

    I didn't find any duplicate "#X connect" lines (and I'm on v0.52.1 anyway).

    The only thing I'm sending to $0-tgl-r is the color message, which shouldn't cause anything to be sent to $0-tgl-s, should it?

    Anyway, I replaced my version with your version (which is much simpler, thanks!), but I'm still getting stack overflow errors. I think it must be something in the abstraction that contains [tgl2], or evern higher up, that's causing the problem, even though "Find Last Error" always points to some place in [tgl2] (not always the same place, though).

    posted in technical issues read more
  • dfkettle

    @oid Oops, sorry about that. Not sure how that happened. Here it is:

    test-tgl2.pd

    How could a wire get doubled? I'm not sure what happens if you draw a connection twice, I would have thought that the second one would just be ignored. I don't think I did that, but I'll take a look. What would I see if I open it in a text editor? A duplicate line?

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!