\[vd~\] and continuous data
Picture a delay as a circular buffer. [delwrite~] is the write pointer, with the size of the buffer given by its argument. [delread~] is the read pointer, with the distance from the write pointer given by the delay time. You can move the read pointer relative to the write pointer to change the delay time, but you'll get clicks because it's not continuous. [vd~] permits continuous modulation, but since it's resampling the signal in the delay buffer, it needs to be interpolated. Anyway, it's not resetting anything or clearing the delay buffer, or anything like that when you change the location of the pointer.
Strange midi issue (delayed midi in data ???)
explanation of my problem :
config : ableton + touchOSC + loopMidi (also tryed midiyoke) (+ PD of course)
I use midi clips, sending CC data (1 cc per clip, only 1 channel used for midi output, to avoid wrong data) so I can use the CC value to make play position cursors on touchOSC.
in PD I set something like that :
[ctlin cc# ch#]
| [Number) ***for monitor purpose, easier to read than [print]
[send /fader $1(
My play position faders are sometimes working perfectly and sometimes they are glitchy, jittery.
at first i thought it was caused by the big number of OSC messages sent by puredata (I planned to do a trick that would filter values after [ctlin] so that it doesn't route redundant values and then only sends different OSC messages. but i got lazy and investigated elsewhere first)
I set a number object after [ctlin] and found that the values are delayed. sometimes cleanly delayed : everything coming late, and sometimes warped : everything ok, but some intermitent lower values. and sometimes for no reasons either it works perfectly. the delays are several seconds long.
in ableton i can see the cursor moving correctly all along the midi clip. if i turn off midi out from ableton during a delay, I still have midi activity for a few seconds in PD
other data are sent & received on time (OSC, midi out)
I only use 1 midi in and out in PD and ableton, via 2 loopMidi virtual cables. audio is off, no delay (1ms)
what could cause that ? it's either between ableton and PD or inside PD
thanks in advance
Compiled external saying "couldn't create" when being added to PD
I'm having trouble getting my external to work, It compiles with 5 warnings
sineq.c:48: warning: unused variable ‘x’
sineq.c:49: warning: unused variable ‘in1’
sineq.c:50: warning: unused variable ‘in2’
sineq.c:51: warning: unused variable ‘in3’
sineq.c:52: warning: unused variable ‘in4’
It does a "make" successfully but I get this warning message
/usr/bin/ld: warning: cannot find entry symbol xport_dynamic; defaulting to 00000000000007f0
but when I try and add it in PD it says "couldn't create". I've looked at the pan~ tutorial and the d_osc.c file as recommended, which did help. I tried to take pieces from the two which I thought were applicable to my situation but I'm still having some issues.
Here's a link to the workflow (dropbox)
Here's a link to the C code online (pastebin)
My external is a reproduction of the sinewave equation with 4 inputs and one output my logic is to have 4 inlets one for the frequency,amplitude,phase and vertical offset and an output for the created signal. Granted this isn't the final equation but this will help me understand how to create the full equation once done. If you want to see the full equation I'll be using here's a link to it below. Basically it's a 1 second periodic signal with the sample rate at 44100 which the equation gives me control over the frequency,amplitude,phase and vertical offset.
Another question I have is what do I use for the t (time) for my final equation is that the t_sample object in PD? or do I need to create a for loop counting from 1-44100 for a 1 second 44100 sampled equation?
PS: I'm compiling on ubuntu 10.04 using gcc
Patching a good reverb
Here's another one, it's a clone of the Ursa Major SST-282. I've based the design on the patents, user manual and service manual, but tuned it myself, and again added some enhancements. I'm not emulating the glitchy, non-interpolated delay modulation and I'm not including the selection of "rooms" (I don't have any information on the delay times here, and they don't seem extremely useful anyway). It's a very idiosyncratic algorithm, and certainly not an all-purpose thing since it turns into weird slush for long decay times (it actually has to, to prevent unstable feedback).
With some modification, it could work well as an initial stage for a more advanced reverberator. You can get away with a large amount of "feed forward" modulation, and the sound can be made extremely rich if it's then passed through some APF diffusion stages, or FDN or whatever. If a signal recirculates through a modulated delay (as in the reverbCH algorithm I posted earlier), it becomes increasingly detuned over time, so this limits the maximum modulation amount versus decay time. So if the goal is to be "lush" sounding, it's possibly better to keep modulated delays out of the main recirculating part.
I've got a selection of original algorithms too, but they're continual works in progress, and much more computationally expensive...
Well, reallocating memory isn't too efficient, and can lead to dropouts during the allocation. So the best overall solution is to just make sure your delay lines aren't too big. And with the gigs of RAM available on modern computers, it would take considerable effort to max out your memory with delay lines. You can get about 100 minutes of 32-bit audio in one gigabyte. Are you sure it's the problem?
Anyway, if you do want to dynamically change your delay buffer, you kind of have to make your own using tables. They're a little tricky, and there are several approaches. But the way I like to do it is to use [count~] to keep track of the write/read pointers, [poke~] to write to the table, and [tabread4~] to read from it. You have to take into account the guard points for [tabread4~], otherwise you'll end up with some aliasing when reading from the ends of the http://www.pdpatchrepo.info/hurleur/diy-delay.mmb.pd
Pdj installation problems -
Hi I am trying to install windows binary of pdj for PD and i am am having some problems,
specifically with a MSVC17D.dll is missing error (i think this dll comes as part of MSVC 2000 troubleshooting installation) which
I cant seem to fix. I am new to java and PD so bear with me but I dont think pdj should be dependent on some dll that came with an old install of MSVC++??
I have latest JDK 1.6 installed & I installed MSVC 2010 just in case
I downloaded the pdj zip file, unzipped it to my c:\program files\pd\extra directory and then added
the c:\program files\pd\extra\pdj directory to the path in PD. I am not sure if i have installed
this external correctly but i can find any more instructions in this regard.
Now when i try to create a pdj object in PD I get a "MSVCR71D.dll is missing error" and the object wont create. If i remove
c:\program files\pd\extra\pdj from the pd path the error is gone.
Can someone shed any light on this for me, i have been banging my head against a wall for a few days with this.
Do you think i need to build pdj for windows using ant to get it working?
Can't load external
I wrote an external, debugged, and it runs like a champ on my main PC. I copied over to another pc (same OS), and PD can't load the external on this second PC.
It's not a path issue, as I put the dll in the \extra dir, and other objects from that dir are loading fine. THere is only one copy of the dll, on the path, so not duplicated.
I'm wondering if there is anything required other than the dll? It was made in Visual Studio, using an SDK for a heatracker. But shouldn't the dll be all that is required in any case?
Swept sine deconvolution
In this case I don't really get the point why you are researching the exact sample value of the peak value. In my experience, analysis of simple IR don't give substantial different results if the time zero of the IR is not exactly on the peak
Some more experimenting has learned me that it depends on the system under test. For an IR of the MacBook internal soundcard loopback, the problem is manifest. For an IR of my room, that is not the case. The difference is probably this: the soundcard's spectrum is near to perfect and there is only a direct response. The room test response missed a lot of the low spectrum end (also due to lousy 'test equipment'), and the direct response is buried in reflections because of the small room size. It's funny that the room response is much easier to trim than the loopback response.
Searching the internet I found the name for the phenomenon: fractional delay. And of course implementations for fractional delay, which can also be used to get rid of fractional delay. As far as I can see now, we'll only need it for cases where the direct response has a prominent role. For example, when we want to produce inverse filters for correction of spectral deficiencies in test equipment. We're not at that point yet.
Anyway, I did a patch with a model of fractional delay, which clearly illustrates the problem. (See attachment). And if you do a loopback test with [IRrecorder], you'll see what I mean as well.
edit: bah, again impossible to attach file. (Did I exceed my upload quotum?). It's here:
Treatment of "midi" information from a 'dj-interface jog-wheel'
recently I had to find how to convert the incoming 'speed' midi messages from a djing controller's jog-wheels in order to get 'classical' [0-127] 'position' values.
To be more explicit, a 'normal non-infinite knob' gives a [0-127] value, and can be used as is. But some 'infinite knobs' or 'jogwheels' provide values that are in fact related to the 'turning speed' : mine gives me speed values between 1 and 30 (after removing an offset and retreiving the 'sign' of it).
I actually managed to convert these [0-30] speed values to position values, using a basic integration scheme, and using a quadratic function to 'shape' these speed values (this had to be introduced to avoid the position beeing dependent of the turning speed). So now everything works, using a semi-empirical patch.
My question is : does anybody knows if there exist a document explaining how this 'turning speed' is coded to give me numbers between 1 and 30 ? Of course this is rather naïve to hope there is some kind of 'standard' used by different manufacturers, I know
It's obvious when you test it that a value of 20 does not correspond to twice the 'turning speed' related to a value of 10. (that's why I used a 'shaping func").
This information, if it exists, could help me to better my empirical patch.
why is this second "1" in [delay~ 1 1] there?!
The first argument is max delay in samples, and the second argument is the actual delay. If you don't specify the second argument the actual delay must be specified with a message in the right inlet, otherwise it will default to zero. That is what I remember from Max Msp and [delay~] is a cyclone object. In Pd it seems to work the same. So the one-sample delay would be a zero-sample delay otherwise!