• jameslo

    @beem I didn't look at David's contribution, but to me it sounds like you want a delay line with adjustable feedback from a variable tap (delread4~). The delay amount simulates the tape speed. I never did this with a real reel-to-reel, but the erase head would have been engaged in record, so the fact that the tape is in a loop is irrelevant, no?

    posted in technical issues read more
  • jameslo

    @beem The thing that's throwing me is your requirement to be able to stop and start the tape. It's been a while since I played with a Space Echo or Echoplex, but I don't remember being able to stop the tape--just adjust its speed from some min to max. Am I wrong?

    posted in technical issues read more
  • jameslo

    I've used the MKR1000 to interact with Pd using OSC or FUDI over UDP/WiFi. For serial over USB, any old Arduino will do I think, but I've mostly used Mega 2560s for their extra I/O pins. I've only done one prototype with TCP/Ethernet and for that I used an Uno with a knockoff Ethernet shield. And for MIDI over USB, I don't remember what I used but it has to be one with a native USB port if you want it to look like a MIDI device when you plug it in. (Edit: I used a MKR Zero for MIDI/USB)

    posted in I/O hardware diyread more
  • jameslo

    @Jess Just curious: what test did you perform to conclude that the bangs you are sending are infrequent?

    posted in technical issues read more
  • jameslo

    @s.elliot.perez I'd also be interested to see what you came up with, and as far as I can tell I'm not high.

    posted in technical issues read more
  • jameslo

    @seb-harmonik.ar Oh I see! I didn't know dsp sort order was influenced by the object creation order. The fact that you can't see it suggests to me that this is one of those behaviors one shouldn't rely on if code clarity is your goal. The creation order can be seen if you open the patch in a text editor, right?

    posted in technical issues read more
  • jameslo

    @jancsika said:

    You might want to start looking at the source for these questions.

    I know, I know.... I can't understand my hesitance.

    That's the intended behavior. I thought @jameslo was complaining that his patch froze the GUI indefinitely.

    Yeah, while the busy wait is happening, I don't care that the GUI doesn't update. But once it's done I was expecting it would update, and I thought that if there happened to be N busy waits in some message evaluation tree, then the GUI would update after each one, but I don't think that's how GUI updates are scheduled. I rewrote the quicksort to remove the slowMotionInstantReplay and insert a busy wait every time 2 table elements are swapped. It looks like the array display isn't updated until the entire sort completes, whereas I was hoping to see each pair swap sequentially.
    quicksort with busy wait.pd
    (This isn't really the behavior I reported earlier when I said it "freezes the UI". In that case the table would only be partially sorted, but I haven't taken the time to reproduce it, mostly because I really don't think this approach is right in Pd.)

    Edit: yeah, I can see now that I wrote "blocking the UI" previously, but think that might have been the wrong way to describe what I was seeing. Sorry.

    posted in technical issues read more
  • jameslo

    @seb-harmonik.ar Ugh, I'm still not following. Could you please post your test patch?

    posted in technical issues read more
  • jameslo

    @seb-harmonik.ar I'm confused. You write about manipulating the dsp graph sort order, but you don't mention using the subpatch/audio connection idiom as described in Pd/doc/3.audio.examples/G05.execution.order.pd. Is there another way? Please show!

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!