• seb-harmonik.ar

    @jameslo said:

    It looks like the second ramp (jump in this case) is still timed relative to halfway through the block though.

    yes that one doesn't have negative delay and the first message cleared the queue already so that one gets processed normally
    edit: it isn't relative to the start of the block, but if you're trying to sync with block-synced objects that would be an issue regardless

    posted in technical issues read more
  • seb-harmonik.ar

    @jameslo I just discovered that if you give vline~ negative delay time value it clears the scheduled ramps and immediately jumps to the value

    so if you use a negative delay time in a vline~ message it will start at the same time as a sig~ one, at the beginning of the block
    it will only work for jumps and not ramps I think, but sig~ only does jumps..
    edit: created a pddp issue to add to the docs: https://github.com/pure-data/pddp/issues/267

    posted in technical issues read more
  • seb-harmonik.ar

    @jameslo this is getting a bit off-topic but it looks like portmidi does have timestamp info on received messages, but afaict PD doesn't use it

    posted in technical issues read more
  • seb-harmonik.ar

    @jameslo midi messages don't have timing info themselves afaik (except for realtime/clock?)
    Therefore they would have to be processed at block boundaries, just as graphical bangs are.
    Not sure how REAPER does it, maybe they store timing info in the queue when they're received on a separate thread or something
    or maybe portmidi supports it and pd just doesn't use the timing info, have to check. But maybe even with that it would be preferable to have the midi events start ASAP on block boundaries since most things in PD are synced at block boundaries

    posted in technical issues read more
  • seb-harmonik.ar

    @jameslo yes it looks like you would have to delay the sig~ one to the next block as well.. (but you could do so by delaying it by a constant 64 samples I think)
    image.png
    (repost, my first test I forgot to resize array2)

    posted in technical issues read more
  • seb-harmonik.ar

    not sure if there's a better way, but I made an object [pib~] a while ago to get the position in the current signal block in ms, using that you could delay a bang to the end of the current block:
    image.png
    https://github.com/sebshader/shadylib/blob/master/pib~.c
    Iirc the bigger issue with vline~ is that it starts the ramp on the value after the 1st value you give it
    If I want to sync on blocks I usually just use line~ unless I need something really precise like reading an audio buffer or karplus strong or something like that.

    posted in technical issues read more
  • seb-harmonik.ar

    @ddw_music I'm pretty sure there's an option to display all of the searched paths that get failed trying to load a certain class, if you run pd at higher verbosity. It will be like "tried xxx and failed" or something.
    Anyways you could use that to see which paths are being tried

    posted in technical issues read more
  • seb-harmonik.ar

    @flextUser when I tried to download it windows flagged it as a virus..
    I would just host the source on the repo host, and wait for deken to upload the release/artifacts
    uploading the .zip file in the repo in the meantime rather than uploading the source and just waiting for deken to upload the package seems like an odd choice

    posted in news read more

Internal error.

Oops! Looks like something went wrong!