Raspberry Pi Audio Output Crackling when Mic enabled
@mpromeo I don't have much confidence that I will help you but......
Try increasing the buffer for audio by setting Delay(msec) to 80 or more.
If that solves the problem then you can decrease the setting until the problem reappears and then set the minimum where it works.
That will increase latency though.
Power could be a problem as the mic input is in a usb device.... You could try attaching the usb soundcard through a powered hub. Is it 44.1K capable..... does changing to 48K help?
((that will not be a solution if all your recordings are 44.1K as Pd will play them at the wrong speed))
And any other usb devices plugged to the rpi at the same time, especially data drives, could cause problems for usb audio I/O.
David.
Another modulation technique (experimenting with wavesets)
To be honest, I hadn't tested the patch before I shared it. Which I definately should have, because I just found some serious distortion problems! Not the kind of distortion that you may want, of course ...
The problem is this: In a digital (sampled) signal you can never really find zero-crossings. All you can get is the first sample after the zero crossing. So I had to calculate an imaginary point between the samples n (> 0) and n-1 (< 0) using linear interpolation. The point of zero crossing then is: n - x[n] / (x[n] - x[n-1])
Fortunately, the vline~ object is sub-sample accurate and can handle this!
So here is an improved version of the patch: waveset-experiments-ms.pd
One more problem might be pd's limited precision. But I've never worked with "double precision" and it would probably be an overkill for this kind of problem anyway.
number frames showing 1 using pix_film and unpack
Hi whale-av thanks for your suggestion .
I already have Quicktime installed.
And I wrote since the problem problem persists after that .
The pix_image problem got solved may be it was due to an issue with the dimensions.
Do you think if I reinstall pd extended the problem might go away?
i am working in a windows machine
this is what I am getting in the comsole
[pix_film]: loaded file: E:/frompendrive/pvt shows/bhavna but small.mp4 with 1 frames (662x538) at -1.000000 fps
plaese suggest
Dynamically patched vslider with local send symbol
@jameslo This is the page you will need for dynamic patching (unless that is where you stumbled)....... https://puredata.info/docs/developer/PdFileFormat
It has the syntax for all Pd GUIs
Yes, unfortunately some GUIs use # instead of $...... a legacy thing apparently that was probably to solve this very problem..... and if you type $ into the properties menu it is changed to # on saving.
No real idea about the escape codes except that I remember that in some interpreters $ is escaped by $....... so $
(seems true on this forum..... that was two dollars in the code quotes) rather than \$
but I don't think that is the case in tcl.
In tcl curly brackets should be used around the $ but sensibly we are not allowed to type them.
https://datacadamia.com/lang/tcl/backslash
But although a backslash escapes it has other meanings as well.
I remember giving the send/receive symbol a simple name and changing it afterwards by message to the GUI as when I was heavily into dynamic patching the backslash was not available in Pd.
Dynamic patches being by definition throwaways that was no problem.
But $\$0
seems sensible to me. I don't think the problem is the $.
The problem is that $0 in a Pd message becomes 0
The message hasn't gone to the interpreter at that stage?
So it is 0 that is escaped and added literally to the preceding $.
$\\\$0
for Pd reading its text file...... no idea...... and anyway I am probably wrong about $\$0
but that change does suggest that the string is being interpreted more than once before it becomes an object.
David.
Having lots of switches into Pd
Thank you for replying and sorry if I am unclear. I will try to slow down a bit.
@alexandros said:
@cfry definitely not necessary to use two Arduinos. I can't really understand where your problem lies.
-The problem is that it does not work when I try to use an arbitrary combination of pins in different modes (Digital in, Digital out, Analog in, Analog out).
Another problem is that I have a hard time reading the code parts that are handling the conversion data in order to do the serial communication, although I understand the principle of it.
You didn't reply to my earlier question about the pinMode calls where you use INPUT_PULLUP on analog inputs. Is this really necessary?
-I assumed that the problem lied in void ()loop as a conflict between the output and input handling sections. And that pinMode calls in void setup() was not relevant in this case. That is why I did not answer that question directly.
Also, why not use the analog pins in an array like with the digital pins? It will save a lot of writing and it's less error prone.
-I was foreseeing that I may want to configure those pins individually, but I can set it up with a loop for now.
One thing you might want to consider is having the Arduino notify Pd when it's done sending all its data and that it's ready to receive. That could be done at the end of the loop() function like this:
Serial.print("done "); Serial.println("bang");
And in Pd have a [r done] object which will output a bang. Use this bang to send data from Pd to the Arduino by unpacking a list with all the accumulated data, possibly with a [list-abs/list-drip].
I use this notification technique in my 3dPdModular system, but there's a LOT of data there and it was only necessary. Perhaps you could try it out.
-I will try that.
Since I consider this to be basically your code I assumed that you could easily just insert the code for both input and output in void loop() in a way that works and that would show me how to solve it. Then I would be able to do further explorations and it would be end of story.
I will digest this a bit and may start a new thread, since this one has slided from "Having lots of switches into Pd" to "having a working code template for communicating between Arduino and Pd using and an arbitrary mixture of pin modes".
Please let me know if this still does not make sense. Thank you so much!
Purr Data GSoC and Dictionaries in Pd
@whale-av said:
@ingox Solving the users problem it seemed to me that Pd is seething with key/value pairs.
To be clear, I'm talking about dictionaries which are collections of key/value pairs. You can use a list, a symbol or even a float as a single makeshift key/value pair, but that's different than a dictionary. (Also known as an associative array.)
The headers/tags float, symbol etc. are used extensively as key/value for message routing.
This is a flat list where the first atom of the list acts as a selector. That's definitely a powerful data structure but it isn't an associative array.
[list] permits longer value strings.
These are variable-length lists, not associative arrays.
The problem for the OP was only that a series of key/value pairs had been stored as a list and that needed splitting.... but it's not a common problem..... and luckily the key was not also a float.
The OP's problem is instructive:
- If you need to send a single key/value(s) pair somewhere in Pd, a Pd message will suffice.
- If you need to store a bunch of key/value(s) pairs as a group (like an associative array does), a
[text]
object will allow you to do that with semi-colon separated messages. The important thing here is that the semi-colon has a special syntactic meaning in Pd, so you don't have to manually parse atoms in order to fetch a "line" of text. - If you want to send a group of key/value(s) pairs downstream, or you want to keep a history of key/value(s) pair groups, you have to start building your own solution and manually parsing Pd messages, which is a pain.
After doing a lot of front end work with Javascript in Purr Data, I can say that associative arrays help not only with number 3 but also number 2. For example, you don't have to search a Javascript object for a key-- you just append the key name after a "." and it spits out the value.
It may be that number 3 isn't so common in Pd-- I'm not sure tbh. But the design of the OP's data storage thingy doesn't look unreasonable. It may just be that those of us used to Pd's limitations tend to work around this problem from the outset.
The old [moonlib/slist] shared keys throughout a patch.
I used to use [slist] extensively as a dictionary, loading it from text files as necessary.
I'll have to play around with that one-- I'm not entirely sure what it does yet.
Keys are already a fundamental part of message passing/parsing.
And the correct way to store them as a string in Pd would have been with comma separators.
(I think...!! ...??)
I tend to use [foo bar, bar 1 2 3, bee 1 2 3 4 5 6 7(
as a substitute for an associative array. But again, there's a limitation because you stream each message separately. E.g., if you have a situation where you route your "foo... bar... bee" thingy to some other part of the chain based on some condition, it's way easier to do that with a single message. But again, perhaps we're used to these workarounds and plan our object chains to deal with it.
David.
Paradigms useful for teaching Pd
This seems as likely a subcategory as any...
I'd like to connect with teachers using Pure Data in the classroom.
- Where are the stumbling blocks that you see students crash into frequently?
- (Anyone using Pd could chime in on that one... what are the things that confused you?)
- Are there any techniques/ideas/paradigms that helped the students to understand these difficulties more easily?
For a specific example: https://forum.pdpatchrepo.info/topic/13263/samphold-at-the-control-level -- "I want to get the number to update on the downbeat so it doesn't play anything while the number is being updated by some other process."
Extremely common scenario -- but I'll be danged if I can find anything in the help series that makes it clear.
This happens to be one of the sticking points for me -- which, lately, got me thinking about a paradigm of "feedforward" and "feedback" to cold inlets. It's (relatively) easy to understand chaining through hot inlets. Everything is immediate, and that's where the quoted question comes from -- if the only thing anyone taught you is how to chain immediate operations, then "save this datum for later" is scarcely even thinkable. (The quoted thread goes on to say "I'm having trouble explaining" -- meaning, whatever degree of exposure to Pd this user had, it wasn't enough to provide a vocabulary to talk about this problem.)
- "I have data now, but I don't want to use it until later" --> feed it forward to a storage object, then bang the storage object when you need it.
- "I want the next cycle of a loop to operate on the result of this cycle" --> feed it back to a storage object that's triggered by the loop.
This solves a bunch of problems. The quoted problem -- (data source) feeds forward to [f] right inlet. Or, initializing a counter at the beginning of the loop (feedforward). Or, building a list iteratively, but outputting only the final list (on each loop iteration, feed the list-in-progress forward to list storage, and bang the storage when the list is finished -- for this one in particular, I had struggled in the past with various bizarre usages of [spigot] but this is much easier).
One of the things I was missing over the last year and a half of getting up to speed in Pd is an established vocabulary of usage patterns. Sometimes I think Pd and Max pedagogy tries to stay away from typical computer-science problems -- but sooner or later, you're going to run into problems that have standard solutions. So why not collect them into a unified place? Like, in SC, for the fourth example below I can just write arrayOfMidiNotes.collect { |note| note.midicps }
and uses of collect
are all over the place in the help system... but in Pd, it took me literally over a year to figure out the best way to collect
/ map
. That's... kinda crazy.
hjh
Error message "invalid command name" , what does it mean?
I get more and more problems: Error messages in the Pd window, stuck GUI (audio running but with errors), Pd crashes, Pd crashes the computer.
Now it is at a point where it is a real problem. At some stage I slow down working on a patch just because I fear it will break, and live of course it is a nightmare.
My impression is that the gui freezing happens more frequently while using large patches with many graph on parent objects. The error messages always writes out when opening or closing a (sub) window.
I try to stay vanilla but I have some external libraries loaded. I use the pduino lib with arduino unos connected over usb.
My main computer is a MacBookPro early 2011/16 gig ram, hybrid SSD/optical drive, OSX 10.13.6 High Sierra.
But the problems are similar on other macs I use: MacBookAir 2012 with Mojave and a MacBook 2009/8 gig, SSD, with High Sierra).
So, how should I go about to report this bug? So I can help in the best way possible? Should I post the patches where the problems occur in?
use table to store midi channel information
I have to admit I'm very fresh to PD, and most probably I did not really understand all of the concepts.
My idea is to split a sequence of key events received on one midi channel to several (random or round-robin) midi channel numbers.
The problem occurs with the noteOff events - there I need to recall the (random) channel-number the noteOn event was sent.
I thought of a list with 128 elements for each note number. Thus setting the channel number when receiving a noteOn Event, and when reveiving the noteOff the channel is read back from the list end send out.
That's working "almost" fine - for one note. But unfortunately the tabwrite object is getting the channel number on its left "hot" inlet just before the note-number is set. Probably because the PD handles the events for outlets from right to left, on the right most outlet the channel appears first, issuing the table writing just before the note-number is set on the right input of 'tabwrite'.
I stretch my head with triggers, routing, spigots, delay, but I can't find a way to alter the order of the inputs to get it working.
Below first - is a simple patch illustrating my problem. When pressing down the first key, the list will show the channel is set for note-number 0 (zero) instead of, e.g,, 44,, pressing the second note, e.g., 48, will store the current channel at list element 44 instead of 48 - thus the channels are always stored for the previous key event.
The second parch below shows what I was working on - including some debugging number-boxes and bangs.
Any idea or hint is highly welcome - thanks a lot
Lou
Why does Pd look so much worse on linux/windows than in macOS?
I have to admit that I forgot to get the Mac screenshot yesterday (smh).
@oid said:
free of the weird artifacts which I assumed were caused by a post screen grab resize, but could have been caused by the screen grabber itself. Lines should not be changing thickness like that, most noticed on the line between [moses] and the number box, they should be 1 pixel wide but it alternates between 1 and 2 pixels in width.
That issue is not caused by the screen grabber. It's the normal appearance of Pd for ages. See the 2nd "Modulation index" --> [*~]. (This is a png -- there are no jpg compression artifacts. This is how it really looks on my screen, in the Pd window.)
"Lines should not be changing thickness like that" -- agreed, but by that standard, then Pd's line rendering is sub-par. Lines in Pd have always been changing thickness, for as long as I've ever used it.
It's a (more-or-less) solved problem in the graphics world. FWIW here is angled-line drawing in SuperCollider (using Qt). Here, I've chosen an angle that will be maximally fuzzy. It's not great exactly but, in my opinion, less distracting than Pd's current display.
whale-av quotes seb-harmonik: "Tk/Tcl has solutions in the pipeline" ... erm... but... again, it's a solved problem. Tcl/Tk hasn't caught up with the rest of the world.
@whale-av said:
Pd I use as a tool to get things done and how it looks is unimportant except for keeping patches clean and readable.
I do understand, but I don't quite agree that appearance is completely unimportant.
For a software community to thrive over the long haul, it needs to attract new users. If new users get turned off by an outdated surface presentation, then it's harder to retain new users.
I've observed, at times, when someone points out a deficiency in Pd, the Pd community's response often downplays, or denies, or gets defensive about the deficiency. (Not always, but often enough for me to mention it.) I'm seeing that trend again here. Pd is all about lines, and the lines don't look good -- and some of the responses are "this is not important" or (oid) "I like the fact that it never changed." That's... thoroughly baffling to me.
I know it's not going to change anytime soon, because the current options are a/ wait for Tcl/Tk to catch up with modern rendering or b/ burn Pd developer cycles implementing something that Tcl/Tk will(?) eventually implement or c/ rip the guts out of the GUI and rewrite the whole thing using a modern graphics framework like Qt. None of those is good (well, c might be a viable investment in the future -- SuperCollider, around 2010-2011, ripped out the Cocoa GUIs and went to Qt, and the benefits have been massive -- but I know the developer resources aren't there for Pd to dump Tcl/Tk). But there's a big difference between "we know it's a problem but can't do much about it" vs "it's not a serious problem." The former may invite new developers to take some initiative. The latter discourages initiative. A healthy open source software community should really be careful about the latter.
hjh