@benrossm [adc~] grabs a sound input from the microphone (if Pd preferences are set to use the microphone input).
[sigmund~] will take the output and send frequency and amplitude data....... as midi note and volume on a scale of 0-100 I think so....... multiply it [* 1.27] for a midi velocity control.
[makenote] will take that data and make a note-velocity-duration message...... and [midiout] will send it.

There are lots of other tools...... see the "top menu"... "help"... "list of objects" for objects that you can use to control changes you want to make before you send out the midi.
David.

P.S........ I should have mentioned that once you have "put" an object you can right-click it to get help with how to use it.
Also the order of connections is Important and you should read and understand this...... https://forum.pdpatchrepo.info/topic/13320/welcome-to-the-forum
Audio connections do not behave in the same way....... the audio thread is a continuous stream of data, but non audio connections.... control data.... need care.

@satsriakal It could be the 32 > 64 bit change. But pyext seems to be maintained so you should be able to update easily if Linux or OSX....... https://github.com/grrrr/py
David.

@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.

@Transcend Did you put [pd-nameofmypatch.pd editmode etc.?
Also I see that in your post you put a space after the . and before pd but I imagine you did not do that in the message.
David.

@Transcend To focus the window put this in your patch.........

..... where "test_popups.pd" is replaced by the name of the patch.
It works in Windows, and hopefully for other os's.... where a simple [vis 1( message fails to focus the window at load time.
Putting a [delay] between [loadbang] and the message might help if it fails.

Then [key] [keyup] etc. will work, although you probably need a window manager active even without a screen, as keyboard messages are always sent to the active window (as you have found...!)
David.

@jermain If you have another soundcard connected then possibly the microphone is not connected to the audio pins that Pd has been told (as it starts) are the microphone pins.
However, someone reported the same problem on Reddit (also for osx) a couple of years ago and found that uninstalling and reinstalling Pd fixed the issue.
David.

@oid I am not sure that you can interrupt the gui/pd communications for a "put" with a plugin. Maybe you could unbind the shortcuts and do what you want with them in a plugin, programming what you need before returning the result to Pd with pdsend.
I spent some time long ago and modified pd_menucommands.tcl and pd_menus.tcl to add a new menu with a drop down choice to the gui window (the files are in woof.zip in the first post of the link below).

That could be a route to try. You can then make your own snippets of code to solve this specific problem, while keeping all other menu items as they are........
https://forum.pdpatchrepo.info/topic/9991/woof-a-new-window-menu-for-vanilla-tcl
The tcl was for Pd 0.46-7 so you would need to paste the parts that I inserted into the two files into the latest versions of them.
Obviously having a backup would be best....
I marked (bracketed) the changes with "MMMMMMMMMMMMMMMMMMMMMMMMMMMMMM"

pdsend is used by undo and redo and editmode in the current version of pd_menucommands.tcl so that gives an indication of how to format the messages that you will need to send to Pd once you have done your modified action.
You can test the messages to Tk/tcl and to Pd from within a patch using the [sys_gui] external..... tcl_message_2.pd ...... has examples of both.
David.

@oid As it is a macro...... could you automate a [click 355 145 0 1 0( message to the window as an alternative to actually clicking it (the coordinates might need to be modified to be within the window boundaries but that is probably not important..... anyway [click 1 1 0 1 0( will always be good.
Then automate a [vis 0( to close it before connecting if that is necessary..... again, with the few millisecond delay if that is then important.
Maybe the messages can originate from within the window but I doubt that...... so you might need a container patch if the macro is within the window.
Of course simply [map 0( + [map1( messages might do the same.
I might well not be understanding the problem, but if it will be of general use and you want to share it then a plugin solution will be best avoided.
David.

@ddw_music I was thinking of the first float received....... if the instant of the button press is important?
That first 1 should pass..... and then the door is shut for the specified time.
[spigot] can shut the door after "correct" data has passed..... and [delay] can then be used to re-open it for a future correct button press without any delay to that data.
I agree that [realtime] is probably over-engineering for a debounce.
David.

@KMETE I think though, that if you want the data to arrive on time, you have to incorporate a [spigot]......
debounce.zip
I could be wrong about that....
David.