Tabplay~ -tabread~
I have build a six shot sampler with tabplay~ objects since these have the benefit of sample accurate adjusting the start adress ( helpfull when recording too late )
But since these are one shot ( adjustable end adress too ) and non transposable , I wonder if there's a method to adjsut the start adress of tabread~ objects .
Assume the tabread is 88200 samples long , but recording only begun after 17500 samples .
I can use the same method as tabread , use as fader 0-1 multiplied by lenght of file into line ~ and into tabread to get to the first audible sample peaks to determine start adress
So I get a tabread of 176400 samples , with 90000 samples of silence at the beginning , subtracting these from the sample length is 86400
SO the Line should start at 86400 instantly , then the second phase are the resulting samples and time correction .of 1959 MS
OK got it
This should be it
90000 0 0 ,17640 1959 0 ,0 0 1959
pack not outputting values from tabreads correctly
This is because the execution-order is not set with [trigger].
If not defined, you can not see, which [tabread] gets the float first. (In this case the order is in the order of patching, which is bad, as we don't want to care about order of patching and we can not see it.) And if the leftmost [tabread], the one going into [pack]'s hot inlet, gets it before the others, [pack] outputs before it packs the other floats.
Put a [t f f f] or [t f f] after [mod 4], where the leftmost outlet goes to [tabread pitch] and the others to the other tabreads.
Doing so, [pack] gets data on its cold inlets first and hot inlet last.
See Pd Vanilla's documentation 2.control.examples > 03.connections
and [trigger] helpfile.
And 08.depthfirst
Pd's order of operation is deterministic.
Hot/cold inlets, right to left order, [trigger] and order of operation are the biggest step in learning Pd imo. So you are lucky this happened now )
How to keep number until turn knob
it gets in the weeds - basically you got a problem if your knob isn't a digital encoder which sends things like +1 or -1 to move numbers - typically these also have a push button.
if your knob is a potentiometer/slider/knob/pot like on an electric guitar - these only give discrete values and will Jump like on the left.
if you use one of those like I am on the right - and I apologize for it seeming messy, I'm cleaning up little problems - but the knob is still a potentiometer, so even tho I changed it into something that compares if its going higher or lower it ends up at weird places - so to do it right these needs to be an encoder type of knob - (which I'm simulating by just hitting the 1 and -1, a little surprised acting like an encoder isn't in [knob] yet.)knob-problems-pot-vs-encoder.pd
Asió Problem
Hi, I am using pure data with the asio4all driver. Sometimes when I open Pd there is no output driver selected and I have to select asio4all again. Does anyone know why this happens??
Some time ago I bought an apogee interface that its controllers don't get along very badly with Pd and I'm forced to use asio4all, but I don't feel it gets along with pd either. All these problems with asio drivers come since I upgraded to windows 10. I would like to know if any of you have had similar problems with windows 10 and Pd or if there is a certainty that windows 7 has behaved better with pd than w10. I'm at a point right now that I don't even want to imagine the problems if I upgraded to w11. I wish it was just my problem, but I'm afraid it's not.
Instability
Hello, first of all I want to say that I have been using Pd for 6 years on a PC i5 (fourth generation) 16gb ram and Windows 7 ultimate. Pd and other DAWs I have have always worked without any stability problems. A year ago I upgraded to Windows 10 home (I have always optimized Windows following the indications offered by Merging Technologies and some professional DAWS) Today all the software related to audio works perfectly and without any problem except PS that drives me crazy.
Just create a new patch with 2-3 tables and 2-3 signal objects to start the instability in Pd.
The first symptom that appears is the "feeling" of "overloaded". For example, when dragging an object with the mouse, the object is delayed with respect to the mouse pointer (the more the object patch is loaded, the more noticeable the delay is)
If I save the content of a table of only 8820 samples for example (200ms) with [soundfiler], it can take between 2 and 3 seconds to wait until the message appears in the console
It has also happened to me (although on fewer occasions) that when I press a bang button, the button remains pressed in black and Pd blocked (although I am not aware that this problem is directly related to the other comments).
I want to make it clear that I have not had any problems related to the audio, it is with the GUI that makes me think that something is not right. The first of the problems that I have named is the one that I consider serious for me, because it prevents me from working at ease and in the end I end up not going ahead with any patch. This happens to me in version 0.53.0 that I have now and in the previous 4 versions. I have used the same patches on a laptop that I have and everything works normally. I can't get to understand what is really happening and what the blissful problem may be related to, I have asked several Pd users on telegram and they have not been able to help me either...
Any ideas that occur to you will be welcome. Thank you!
Pd and GEM crash when using auto 1.
@thisprogramsucksonwindows For more...... https://forum.pdpatchrepo.info/topic/13772/loading-a-mpeg-file-in-pix_film-is-creating-problem-0-frames-why
It seems uncertain where the problem arises and no-one has posted a solution. Gem is broken somehow in the 64-bit environment.
32-bit Pd + Gem was pretty stable (Pd extended) and Vanilla and extended can be run at the same time without preference conflicts in windows.... so I would suggest that you open extended +Gem for the video, and Vanilla for other stuff..... and communicate between the two with [netsend]+[netreceive]
You will find Pd extended here....... https://puredata.info/downloads/pd-extended/releases/0.43.4 ... including a portable (run anywhere) version. The preferences are stored separately to Vanilla in the registry.
It should play an AVI without problems I think.
David.
Camomile UI Problems
Hey all,
I've been trying to get started with Camomile to make some plugins to share with friends, but I've hit a problem I haven't been able to find mentioned anywhere.
After using the script from the latest stable (I've also tried this with the latest experimental release), to build plugins, when I try to open them in Logic, I just see a loading symbol in the plugin window (see attached picture). This problem occurs with the example plugins and plugins built by others (e.g., Mike Moreno's Lira 8 ).
Even weirder is I've had the same problem on an Intel 2014 MacBook Pro and an M1 2021 MacBook Pro.
Maybe I'm being an idiot and missing something?
Anyone else had this problem and knows a fix? It'd be super appreciated!
Convert analog reading of a microphone back into sound
@MarcoDonnarumma Unable to see what is contained in the sub-patches I don't know how you have regulated the timing. The incoming messages have no clock as far as I know....... the messages arrive when the socket connection spits them out. I see you are measuring the sample period, but is that averaged or continuously updated?
Is there something in your patch that writes the samples at the correct time?
Maybe you could time stamp them in the sender?...... and then use [tabwrite] to index them correctly.
But are you sending repeated bangs? from [r $0-metroreg].
[tabwrite~] needs just one bang to start and will write at your Pd sample-rate (maybe 44100 samples per second). So maybe your array1 is simply far too small to show the data? You need to choose the arraysize for the time window you want to look at and then bang [tabwrite~] at that rate (new window draw as the last finishes).
If the scope is still "blocky" because of your actual low sample-rate of 500Hz you can interpolate afterwards.
This....... https://support.audient.com/hc/en-us/articles/202587353-Clocking-Explained sort of goes into the subject, but essentially samples in the wrong place introduces distortion and when there is enough distortion all you get is noise.
David.
P.S. Lastly (probably not) a 40Hz signal is inaudible for a lot of people. But with a low sample-rate the waveform will be drawn as blocks rather than a smooth curve (at 44100Hz), and your ears will hear it because of the sharp steps (almost like a square wave) in the waveform.
So maybe your patch is actually fine?
Haha here we go.... you can smooth the samples like this..... https://forum.pdpatchrepo.info/topic/11850/explanation-for-lop-object-in-this-patch-requested/2
.... a sort of "pre-interpolation" if you wish, that will smooth for the higher sample-rate in the [tabwrite~] array.
summer: an additive synthesizer with per-partial ADSR amplitude envelopes & LFOs
I took a shot at optimizing a bit. the main patch looks good but in addosc there are a few little things (which may add up bc you have 224 of them):
[tabread~]
is taking a control-rate input. So, it isn't doing anything that [tabread]
couldn't do, and have it translated to a signal later down the graph instead. The difference is that [tabread~]
will still process the last input every sample whereas [tabread]
will only output when it gets a new message. (so you'll be doing about samplerate times fewer computations if you have a new input every second)
similarly [+~ ]
and [*~ ]
are more efficient if you use the versions with a control-rate right inlet bc the loops can be vectorized and maybe predicted better. (to do this supply them with a float argument).
generally the arithmetic objects are more efficient than the [expr~]
family. And, [expr~ 1 - $v1]
is also another case of not needing the signal version bc the input is control-rate (after changing it to [tabread]
). Instead you can change it to [1 $1(
going into a [- ]
. (tho in this case idk if it is actually better than [expr 1 - $f1]
bc we also have to process/send the list from the message box.. the main thing is making it control-rate tho)
The final little thing is replacing the division [/ 127]
in the adsr subpatch by multiplication with the reciprocal, bc processors are better at multiplying than dividing. You can do this any time you're dividing by a value that won't change.
hope it helps
addosc.pd
as for locality I think the only way is to use $0 in your arrays like you say.. you might consider making addvoice an abstraction as well. Then you could supply $0 as the argument, and inside supply it as the 2nd argument of [addosc]
with $1, which could then use it as $2 in the [tabread]
s to refer to the grandparent's $0
that way you'd only have to edit 28 [addosc]
s instead of 224
Midi Rotary Knob Direction Patch/Algorythm?
Hey everybody,
Sorry, for a lot of text. But the bold text at the bottom is my main question. The rest will help you to get a better understanding of my situation.
you helped me so much, with my last question here (the Faders are working dope now):
https://forum.pdpatchrepo.info/topic/13849/how-to-smoothe-out-arrays/25
I am doing a Steinberg Houston to Mackie Control emulation at the moment, to use my controller with other DAWs than Cubase/Nuendo. Will upload it to the internet community, when I am finished for the handful of people that maybe are also using this controller.
I made good progress:
I got the Faders and the normal knobs to work. And the display puts out information. But it is with bugs, because the LCD Screen of the Houston has 40 characters for one line and the Mackie Universal Pro has 56 Characters. So i did a list algorithm, which deletes spaces of the mackie message until the message fits on the 40 character line. Maybe there is a method wich will work better but this subject eats too much time for me at the moment and it works rough okay. One defenitely get's some helpful information on the screen from the DAW.
The Faders and Rotary Knobs and normal knobs are the most important of this controller I guess. The Faders are working fine as I mentioned above, but there is a problem with the rotary knobs, wich I can't handle alone and hope you can help me.
The problem is, that the Mackie Controller send simple clicks to the DAW. If you are turning a rotary knob, it sends out a number of midi messages:
If you turn it right, it sends midi messages wich contains the value 1 and if you turn it down it sends messages wich are containing the value 65.
"When the VPots are rotated rapidly, a message equal to the number of clicks is sent."
BUT the Houston controller instead is sending values like it's faders with 15 (MSB) and 128(LSB) values. AND it is updating the rotary limit by itself. So if I turn a rotary, it will update it's LEDs and stops sending midi messages when it reaches the maximum or minimum value. So, I did this patch as a momentary state:
The DAW sends 11 values for the Houston LEDs. 11 is max and 1 is min. This is good, I send this values to my houston controller and can update the rotary values and LEDs.
With this updated values from the DAW, I can force my rotary knobs, that they don't stop to send values, because they are set to the values, which the DAW sends, every time I turn a knob. With this method I got it to work to imitate a Mackie Rotary knob. Everytime the Houston Rotary value changes, it sends Mackie "midi click values" according to the amount of midi value changes of the houston.
BUT the problem is, that this is working only in one direction. Now my main question:
How can I make pure Data know, if I am turning my knob in the left direction or in the right direction? There is also the problem, which I mentioned above, that I set the momentary value everytime, I move the rotary, so that I get a unlimited amount of possible rotary move "clicks". Also the midi values which the houston sends arent perfect smooth. It works fine, but it isn't like that, that if you move a rotary in one direction, every value one by another is perfectly lower or higher.
I think I maybe need a algorythm, which looks if the values in a time period are getting higher or lower and then send out bangs on two seperate outlets. For example the left outlet for lower values and the right outlet for higher values. And it should also detect, if I move the rotary fast or slow. So a constant smoothing or clocked bang is also not an option. This is defenitely to complicated for me. I have no idea and what I tried didn't worked.
Would be super cool, if you could help me out again.