• seb-harmonik.ar

    @oid wow that is involved.. I'm trying to wrap my head around it, but did you try just putting the [del 0] right after the [loadbang] in m.pd?

    not sure about the [closebang] stuff.. why not just do everything before triggering [canvasdelete]?

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

    @Itsuki usually delay lines are implemented with a ringbuffer. You can find an example in the source for [delwrite~] and [delread~]:
    https://github.com/pure-data/pure-data/blob/master/src/d_delay.c

    in short, constantly write to an array every sample and wrap at the end of the array. Then you read 'behind' by however many samples you want the delay to be

    posted in extra~ read more
  • seb-harmonik.ar

    @oid I think I fixed the bug in this one; maybe it can help with the other more complex object.
    msg.pd
    basically, I changed the order:

    loadbang - object is created. in the event of autopatch, new blank object is also created in the parent patch and connected to

    after a delay of 0 (meaning the scheduler puts it after everything else currently on the scheduling list) the new message box is created, and its index is queried as the last item in the canvas (because autopatch may have created a new object in between [msg] and this new message box in the meantime). All connections are fixed.

    after another delay of 0, [msg] deletes itself

    Edit: actually I'm not sure all those delays are necessary.. I'll look at it again later. I think the main thing is that the auto patched object is created before the dynamically created ones (and that usage of [canvasindex] takes that into account)

    Edit2: turns out the [del 0] before the deletion wasn't necessary. updated the patch (& also [declare]d the iemguts path)

    posted in abstract~ read more
  • seb-harmonik.ar

    @oid have you tried using iemguts objects for this? specifically [initbang]?
    posting the patch may help as well..

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

    you're going from control-rate to signal rate (a somewhat complex topic)
    going off david's discovery, the 'resonances' (which are probably actually aliasing components) probably correspond to the fact that control-rate messages interact with signals every 64 samples, and you're probably running pd at 44.1 k samplerate (effectively you're 'sampling' the toggle every 64 samples)
    In order to create waveforms using control-rate you have to use [vline~] but there are much better ways to do this at signal rate, even without anti-aliasing:
    https://mikemorenodsp.github.io/basic-waveforms/

    posted in patch~ read more
  • seb-harmonik.ar

    @ddw_music I might take a look at this and add the preference to pd-next too, if it isn't accepted. after all it's just an aesthetic/editing thing that doesn't affect the objects or patch format at all..
    I think another option would be to have a keybinding to edit currently selected object(s?), since the users who want to edit object text after ctl-d need to use the keyboard at that point anyways

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

    @danomatika I remember someone giving some reason for reverting but still feels like a strange decision imo.
    Maybe there should be some option/preference..
    edit: ah, I see in the thread you make the same suggestion..

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

    @jameslo well in the paper they ignore rotation a bit also in that they consider the algorithm to stop when the remainder is 1
    I doubt @Stutter is checking the forum anymore unfortunately, maybe someone can re-derive thons work..

    posted in patch~ read more
  • seb-harmonik.ar

    You might be able to accomplish something like this by putting a data structure in a graph manually yourself.. I'm inexperienced w/ that but I think it is possible..

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!