• whale-av

    @Jona All work by @cuinjune I think......
    You need [s2f] for [s2l] to work, but you could embed it as a sub-patch.
    [l2s] [s2l] [s2f]
    ls2_etc.zip
    Let me know if something else is missing.
    David.

    posted in technical issues read more
  • whale-av

    @Balwyn You are very welcome. Credit to @cuinjune is due for putting in the work for a vanilla version.
    The serious external writing in the 2000's suffers from its own success. There is so much great stuff to trawl through and remember!
    David.

    posted in technical issues read more
  • whale-av

    @Jinkgo Give the canvas a "receive symbol" in its properties....... and then you can send it the label text directly......
    Here is [l2s] for vanilla........ l2s.pd
    David.
    Capture.JPG

    posted in technical issues read more
  • whale-av

    @Balwyn @Jinkgo Yes, if you set size width and height all to 1 (the minimum) and shift the label to cover it. But as you know where the canvas will be on the jpeg you could colour match the single pixel to the jpeg as well, so that it is invisible even when there is no label.
    David.

    posted in technical issues read more
  • whale-av

    @julibla2 Not easy to tell. I will start at the end.
    If you cannot create [dumpOSC 11112] it is because Pd is already listening to the same port.
    Do you have 2 or more of them in your patch?
    You can only have one [dumpOSC 11112] in your patch.

    If you are only using [dumpOSC] in Pd then it looks like it is not Pd causing the problem for Processing.
    Unless you are also sending back to Processing from Pd using [udpsend]?

    If you are doing 2 way communication then you need 2 different ports.......
    1 port to send from processing to Pd
    2 port to send from Pd to Processing.

    The server...... in Pd [udpsend] needs to open its socket (broadcast that it is on the network)..... so that Processing can connect and listen to that socket. I do not know how Processing does that.

    The client........ in Pd [dumpOSC] needs the server in Processing to broadcast its socket so that [dumpOSC] can connect.

    If you open Pd first and then Processing complains then either you have created [udpsend] on port 11112 already..... so Processing cannot create the socket, or Processing has already opened it, or some other program has already opened it.
    It is used by "ACR/NEMA Digital Imaging and Communications in Medicine (DICOM)"
    If you recognize that organization then that would be your problem.
    Very unlikely though.

    Another thought. It could be, if you are restarting the programs very quickly after shutting them down, that the sockets have not been released after previous use. You could Google "TIME_WAIT" and "SO_REUSEADDR " for more info.
    Usually the sockets are locked out for 30 to 120 seconds...... https://stackoverflow.com/questions/3229860/what-is-the-meaning-of-so-reuseaddr-setsockopt-option-linux/3233022#3233022
    [udpreceive] sets SO_REUSEADDR so could be a better choice than [dumpOSC] which does not.
    David.

    posted in technical issues read more
  • whale-av

    @oystersauce You are looking for freeverb~ ...... which has been compiled for 64-bit windows and is available on Deken.
    I am pretty certain that your recent posts are all about the same problem.
    If nobody has recompiled an external for 64-bit for the OS that you are running (and added a link to Deken) then Deken will not find it.
    Some externals might have been compiled but not added, some have not been compiled, and maybe some cannot be compiled.
    You might find repositories for the C code on github that will allow you to compile for your system.
    Please share them afterwards as it will help others with the same problem.
    64-bit Vanilla is starting to have some useful tools, but if you don't need them or the higher precision of 64-bit then Extended or Deken for 32-bit Vanilla are still a better bet at the moment.
    Of course on a 64-bit OSX that is not an option.
    If you are willing to try a fork like Purr Data then the developers are often more active and willing to help rebuild old (or even new) externals for their version.
    A lot of people have been looking for [knob] and @yoichi_tbbb recently made a great one here........ https://forum.pdpatchrepo.info/topic/10938/new-knob-gui-object which I am surprised no-one has compiled for 64-bit.
    David.

    posted in technical issues read more
  • whale-av

    @jameslo Amplitude does not estimate the peaks between measured spectrum frequencies.......... http://www.ni.com/white-paper/4278/en/#toc4 so with only 511 points in the mask table power should be a better choice.
    I cannot get my head wrapped (good pun) around the combination of the block size and up-sampling in relation to [tabreceive~] but you will probably find that it doing what is explained in the above link.
    I will post again if I get there...!
    If I was trying to achieve the same thing I would have been bogged down in an object that interpolates, but Miller is much better educated than me.

    I don't understand why the patch was called "noise gate" though, when it is noise reduction by process.
    It seems to do as good (usually bad) a job as the pro daw equivalents that I have.
    The multiplier at 15 does a very good job of totally cancelling all of a Pd noise source set to 100 on the generator. I assume the math is correct.
    David.

    posted in technical issues read more
  • whale-av

    @pure-data-troubles It means that the OS is not responding to calls to bind to any HID devices. The most likely reason is that Pd HID is still 32-bit, and your version of Pd is 64-bit.
    You will probably have to find the source for HID and re-compile for your system.
    If you are using windows you could use a 32-bit version of Pd Vanilla, but you will be stuck in the past, and extended is more useful.
    David.

    posted in technical issues read more
  • whale-av

    @oystersauce High frequencies have fast changes between samples.... low frequencies slow.
    So [lop~] allows slow changes in the signal domain.
    get.pd
    Fast changes are suppressed..... producing a curve....
    But. The signal still has to get to the value requested. If its slope is being reduced then it will take more time....
    In my patch above the time to change is 1 ms, so 1KHz, and the time is more than doubled with [lop~ 0.3] . I probably should have set [lop~ 3] to better match the curve in Andy Farnell's patch.

    What does it mean for audio....? The phase is shifted to the right. There is a lag compared to the unfiltered signal..
    David.
    Capture.JPG

    posted in technical issues read more
  • whale-av

    @Transcend Yes. [tabread4~] interpolates using 4 consecutive samples. It uses the one before and the two following the one it is assessing.... and in effect it guesses (by calculation) what the original analogue waveform would have been.
    Because samples are taken by an Adc at precise times the individual samples, especially for high frequencies, are necessarily NOT the peak and trough values..... so by doing some math it tries to estimate the original. The more math is done the closer it will get, but it rapidly becomes very expensive in processing. Failure is called aliasing. Usually those frequencies likely to fail are filtered out in the Adc, but of course Pd can make its own. Digital video and even fonts on your computer screen have the same problem...... data points that fall between two possible digital representations of the original.
    It is likely that a decent Dac in a quality soundcard will do it better, along with a lot of other clever stuff.
    Included in the Pd doc folder in your installation is a sort of tutorial. Interpolation is demonstrated in "B04.tabread4.interpolation.pd"
    Work your way through that doc folder (3.audio.examples)..... and it will gently introduce you to FFT..... although you will then probably need to do some external reading as well.
    David.

    posted in Off topic read more
  • whale-av

    @Transcend Ahh..... that is where the confusion arises. What is being read is individual samples.... at 44100Hz sample rate there are 44100 every second. The pitch is heard because of the rate at which they rise and fall in value.
    In Pd a sine wave at 100 Hz would have a sample value of zero (maybe, it depends at what time the wave starts) at index 0, and then rising sample values to a value of 1 at sample number 110 (more or less) falling back to a sample value of 0 at sample 220, continuing to fall to -1 at sample 330 and then rising back to a value of zero at sample number 441....... etc. etc.
    When those values are read by [tabread4~] the output would....... eventually, once it gets to your speakers..... push and pull the speaker smoothly 100 times a second, and be heard as 100Hz. Depending on the bit-depth of the dac the actual sample values later in the chain will be much larger, but Pd max/min values are +1/-1 at the output to the [dac~]. Your soundcard and Pd take care of that automatically.

    If there is another sound, say at 1KHz., that would modulate that 100Hz wave..... it would look like a ripple on the 100Hz wave........ and so on. A music track will look a real mess when you look at it, with only loud / quiet parts really recognisable. But our ears, or more especially our brains, can make total sense of it.

    Samplerate (audio) objects are used to set the indexes because they send a value at the samplerate...... so 44100 times a second...... so every single index is sent to [tabread4~]
    Digital audio (FFT) is fiendishly complicated to understand, but this gets you quite a long way into it in only a few minutes........ https://medium.com/@djtech42/explanation-of-sample-rate-in-digital-audio-and-breakdown-of-misconceptions-38f912fb3b1f
    Actually it gets you a very long way toward a good understanding in just a few minutes.......
    David.

    posted in Off topic read more
  • whale-av

    @Transcend Yes, [phasor~] just scans through the indexes at a desired speed and over a desired range, and [tabread4~] returns the sample values of those indexes at the audio rate.
    [phasor~] actually sends a ramp..... 0 to 1, fall instantly to 0 and another ramp...... so a sawtooth 0 to 1 at the frequency that is sent to its left inlet. So to get it to play all the indexes its output needs to be multiplied by the total samples.
    The frequency needs to be set that the time for each ramp is the same as the normal time length of the sample....... for playback at normal speed. Changing the frequency will speed up or slow down playback, and inverting the ramp (horizontally) will play backwards.
    [mess] uses some math which changes as random numbers arrive........
    The [*~ 1] will change the start point and the speed at the same time. They could be separated using a [+~] as well, but I kept it reasonably simple. The speed changes the frequency, but does no stretching (to maintain the time length of what is played) so higher pitch will be shorter, lower pitch longer.
    The Grain slider changes the rate at which random numbers arrive, and [random] spews any number between zero and the size of the array..... a value that it gets from [soundfiler].
    The [phasor~] gets its frequency from dividing the samplerate (I assumed 44100) by the number of samples, so that if nothing was messed up it would simply play the file at the correct speed from beginning to end repeatedly.
    The [spigot] allows the same random numbers to change the frequency of [phasor~] as well.
    You can reset that by closing the spigot and clicking the [44100( message. The clicking of the message could be automated by a bang when the spigot is turned off like this........ mess.pd
    David.

    posted in Off topic read more
  • whale-av

    @jameslo Oh well. Another win for "extended" then.....
    Thank you for doing the testing.
    David.

    posted in technical issues read more
  • whale-av

    @jameslo Did you try putting separate [ctrlin] objects for each midi fader into a sub-patch and using send and receive objects to the main patch (not opening the sub-patch or the "Test window".......ever....!)?
    It would be interesting for others if that is a solution.
    And I wonder if the NanoKontrol2 still sends to the non-existant midi ch 0 from the first fader, as the older one did? Could that mess up the messaging?
    David.

    posted in technical issues read more
  • whale-av

    @jameslo Maybe a solution from @Berenger....... https://forum.pdpatchrepo.info/topic/3651/midi-input-cpu-overload
    A quick Google says that Pd is far from being the only midi receiver that has problems with the Nanokontrol.
    David.

    posted in technical issues read more
  • whale-av

    @Transcend Of course. It is all just math. You can do what you wish.
    This will randomly mess up the read...... mess.pd
    Of course, the more you mess it up, the less it will be in any way meaningful to your ears.
    David.

    posted in Off topic read more
  • whale-av

    @amirt Do you mean the contents of the abstraction are created dynamically, or the abstractions are placed in the one (or more) sub-patches dynamically?
    If the latter then it should work....... demo3.zip
    TURN the volume DOWN..... it will create 10 copies.

    If the former then don't forget that when you save an abstraction all copies will change to that saved file and be re-loaded.
    David.

    posted in technical issues read more
  • whale-av

    @Balwyn To me "menusave" seems the least disruptive...... here saving the abstraction so as not to change the main patch. The delay is unnecessary, but suppresses an error message.
    The abstraction will not have changed so it is not harmful.
    No need to write menusave into the abstraction, but @ingox had the original idea.
    Vanilla and Extended.
    demo.zip
    And the delay is unnecessary if an incoming message initiates....... demo2.zip
    It simply automates what @amirt was forced to do to make it work.
    David.

    posted in technical issues read more
  • whale-av

    @Balwyn You can also just turn on DSP directly in the abstraction, rather than turning it off and on in the sub-patch or doing any editing........
    Capture.JPG
    Although that will crash Pd if DSP is not turned on, generally, already. So probably a message to Pd to turn dsp on first would be best.
    demo.zip
    AAArgh...... extended only..... doesn't work for Vanilla.....:expressionless: :question:
    David.

    posted in technical issues read more
  • whale-av

    @amirt The [catch~] will add all the signals together so the output signal will have to be reduced. It is hard though to know exactly the resultant level..... it will depend upon what is being sent.
    If every [throw~] is sending an [osc~] output signal then divide the [catch~] output by the number of throwers...... https://forum.pdpatchrepo.info/topic/10018/does-throw-really-sum-signals/3
    If only one [throw~] is ever sending a signal then the divide is unnecessary.
    If your [throw~] levels are unknown then that presents a conundrum.
    In the "zexy" library there is a "feed forward" [limiter~] setup in the [limiter~] help file, which, if a small extra delay is acceptable, would keep the signal in range, but probably sound compressed.
    You could then divide by a smaller number........ and follow that with a limiter.
    David

    posted in technical issues read more
Internal error.

Oops! Looks like something went wrong!