• oid

    @blindingSlow There is a fair amount of information there but it is mostly just variations on the same methodology so once you get the basics down it comes quickly. Regarding drawing waves, sometimes it can be better to use a fixed frequency oscillator for the display and just duplicate everything for the part you are listening too. Everytime you resize an array you are reallocating the array which is not the fastest process and if you turn the frequency of your wave low down to 0.1 hz you have to wait 10 seconds for it to update the display. With a fixed frequency you avoid reallocating memory and keep the display responsive but you are asking more of from the UI with all those updates and if you are doing a good deal of manipulation to the waveform duplicating everything could be more expensive than the reallocations. Need to find the balance between trade offs for the given situation.
    wave.png
    display.pd

    Also, just remembered you had some eyesight issues, was my screenshot readable for you? If I am just uploading a screenshot of something basic which does not require the patch to demonstrate should I do the screenshot zoomed in or always upload the patch?

    Edit: If you were going to make a display like this to use in a patch and not just learning you would want to stick it in a subpatch so you can use [switch~] to turn the duplicated objects off when the display in not being updated.

    posted in technical issues read more
  • oid

    @blindingSlow
    Give a read through the help files for messages and graphical arrays.
    Untitled.png

    posted in technical issues read more
  • oid

    @jameslo said:

    PS is it still called "duty-cycle" if it's not a square wave? I'm not a synthesist.

    In the synthesis world that would generally be called variable slope. I don't think this would be variable duty cycle from the electronics standpoint either since duty cycle refers to the on vs off time and that remains constant in this use. A variable duty cycle triangle would essentially just be a [clip~ x 1].

    posted in technical issues read more
  • oid

    @blindingSlow You can use [resize( method for array or [array size] and a little math to change the array's size to what it needs to be for a given frequency. To make it work with any samplerate you can use [samplerate~] to get the samplerate which pd is currently ruining at.

    posted in technical issues read more
  • oid

    @ddw_music He was referring to the startup flags, start it from the terminal with -verbose and see what prints in the terminal. You could also try specifying the library on the command line, might get some extra print out that way if you are lucky. I seem to recall once upon a time getting a vital clue that way.

    posted in technical issues read more
  • oid

    @dvd01osclfo You can also use the [array] objects to interact with graphical arrays.
    Untitled.png

    posted in technical issues read more
  • oid

    @rph-r Didn't know escaping with [command] worked now, good to know. Wonder how many years I have been doing unneeded elaborate work arounds.

    posted in technical issues read more
  • oid

    @inari All the stuff for cos_table looks to be in d_osc.c for me, not finding anything grepping m_pd. What version of pd are you using? They did change some of this with 0.55.

    actually kind of breaks OOP

    I think part of the reason I have issues getting OOP down is because anytime I do a search looking for elaboration on something I always seem to find one of those big long largely philosophical discussions on OOP and get sidetracked, they are often started by a comment like yours.

    Edit: looks like [vcf~] no longer calls cos_maketable but [osc~] still does.

    posted in technical issues read more
  • oid

    @inari Opps, I conflated t_sample and t_samplerate, pretty sure I got myself turned around on C's OOP again as well. What global? Pd is more concerned about doing things in the most efficient way possible from the computation standpoint, hence all the pointers and the like, it often leads to less than ideal code from the reading perspective. Miller has a videos explaining the guts of pd in depth plus history/theory of this stuff, it is on his website under "classes" look for something like "inside pure data." The first couple videos unfortunately have an audio issue but you can mostly make out what is important, msp.ucsd.edu. There are also some older videos which can be found on the web, I don't think those have audio issues but no idea which is better, I have yet to have the time to sit down and watch through either in their entirety.

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!