Accessing BPM and time signature of Plug-In Host - audiounit

I am working on an audio plugin and would like to map LFOs to various parameters. How does the plug-in access the DAW's BPM value and time signature?
Does the host need to expose this through VST or AU protocols or how should a plug-in access properties it needs during runtime?

For anyone with the same requirement, the JUCE library has an object called AudioPlayHead
You can then get the current position info inside your processing callback
audioPlayHead->getCurrentPosition(currentPositionInfo)
and then access the BPM on the position info using currentPositionInfo.bpm

Related

Detecting touch properties of the screen

Is there a way in QML or Qt or C++ to know if the screen (or the platform) support tactile, and more specifically, if the screen support multitouch
Is this even possible ?
EDIT :
On windows it seems we could try to enumerate the device to find one that match
https://support.microsoft.com/en-us/kb/259695
This should also be possible on linux
RELATED :
What's the best way to detect a 'touch screen' device using JavaScript?
Is there a way to determine if the current screen supports touch?
You can use the static QTouchDevice::devices() function to enumerate the available touch devices, and the capabilities() function to check the capabilities of individual devices. To check for multitouch support, you would probably call maximumTouchPoints().
The QTouchDevice class describes the device from which touch events originate.
Each QTouchEvent contains a QTouchDevice pointer to allow accessing device-specific properties like type and capabilities. It is the responsibility of the platform or generic plug-ins to register the available touch devices via QWindowSystemInterface before generating any touch events. Applications do not need to instantiate this class, they should just access the global instances pointed to by QTouchEvent::device().

Obtaining width of WiFi networks programmatically

How do I obtain such information? After digging around I was able to find the opcodes used with WinAPI
WLAN_INTF_OPCODE enumeration
However I couldn't find the necessary means of getting information on the channel width.
Unfortunately, Windows Native Wifi Api does not present the channel width information directy. But this (as well as many other parameters) can be obtained from the Wi-Fi Beacon frames transmitted by the access points.
This information can be accessed by the WlanApi WlanGetNetworkBssList function, which returns a list of WLAN_BSS_ENTRY structures (https://learn.microsoft.com/en-us/windows/win32/api/wlanapi/ns-wlanapi-wlan_bss_entry). Via that structure you have access to all the Information Elements present in the received beacons, but you have to parse that information yourself.
I needed this feature in the project I'm working on, so I found a Python wrapper library for the WlanApi (win32wifi) and added this feature to it. You can check it out on github (https://github.com/opetryna/win32wifi/commit/35bc65df12ae8e3c579f4e867b3bfcadfb6e072a).

Qt Bluetooth Low Energy - Problems using non standard GATT

I have a device without knowing the used gatt profile, I only know that is something "homemade" and not anything known on the bluetooth-database.
In Linux the command
gatttool -i hci0 -b xx:xx:xx:xx:xx:xx --char-read --handle=42
returns the value as expected (with the target device mac at xx:xx:xx:xx:xx:xx).
In Qt I am using the Heartbeat-Example from http://doc-snapshot.qt-project.org/qt5-5.4/qtbluetooth-heartlistener-example.html
there they connect using a gattprofile, QBluetoothUuid::HeartRate and QBluetoothUuid::HeartRateMeasurement
I wasn't able to modify the example code in a way to read handle 42.
Can you explain where I have to put which values, that it connects to the "standard profile" as the gattool command does? If I use gatttool in interactive mode and ask primary it returns two uuids, but using them instead of the QBluetoothUuid::HeartRate did not work.
It doesn't appear that the Qt Bluetooth Low Energy API provides means for obtaining access to characteristics based on their handle value. (Neither does the Windows 8 BLE API.) You should use the UUID. Even if it's a homemade device, all services and characteristics are required by the GATT protocol to have UUIDs. The lowenergyscanner demo app can discover and display both the UUIDs and handles of all of the device's services and characteristics. I've used lowenergyscanner to deal with BLE devices I'm developing.
device discovering is by uuid, even if you create a new profile with a new service and a new characteristic, you have to give the new characteristic uuid in setup.
But i dont know, how to add multiple characteristics to one service, it does not work with me.
have fun

How to customize right click with already existing instance of a program?

I need to customize right click so that I can scan a directory with my anti-virus. I know how to do that using registry keys, but the problem is that I don't want to start a new instance of my program every time I want to scan a directory. My anti-virus needs to load some signature databases so it will take around 15 seconds for the program to load those. I need to use the instance of the program which I have already opened and is running for scanning the directory. How can I do that?
I am using C++Builder.
Thanks.
Considering you already know how to add the item to the right click contextual menu, I suggest implementing a client/server set of applications:
A server that loads up when you turn your computer on and does the scanning, and
The client that tells it what to do using IPC - inter-process communication.
You then add the client application to various contextual menus, passing it arguments that indicate what it should get the server to do depending on what you right-clicked on.
IPC is a bit of a pain in the butt, the easiest way is to use TCP/IP to and do local networking using a network library. There are many out there, however given you'll likely want to have other features such as UI elements and a tray icon, I suggest you look at Qt, namely the following components:
QtNetwork: For performing communication between the client and the server executable.
QSystemTrayIcon: For displaying a small icon on the tray.
There are quite a few other little bits of Qt you'll no doubt encounter (like all the fabulous UI stuff), and fortunately Qt is well documented and help is always available here, and from the Qt Developer Network. You can get started with Qt by downloading and installing the SDK:
http://qt.nokia.com/downloads/
Best of luck :).
Implement a DDE server in your anti-virus, and then add a ddeexec subkey to your Registry key. Alternatively, add an OLE Automation object to your app that implements the IDropTarget interface, and then add a DropTarget subkey to your Registry key that specifies the object's CLSID.
Either way, whenever your menu item is then invoked, Windows will call into your existing app instance if it is already running, otherwise it will launch a new instance and then call into it. Either way, Windows is handling all of that for you. All you are doing is providing an entry point for Windows to call into.
I would suggest the IDropTarget method, because DDE is deprecated, and because IDropTarget is more flexible. While your app is running, you could re-use the same IDropTarget object to handle OLE Drag&Drop operations on your app's UI window and Taskbar button, and support automated invokations of your scanner by other apps.

Is there any method of accessing a remote filter graph without registering proppage.dll on Windows Vista+?

I'm currently attempting to developing a small application / dll that will read a remote directshow filter graph and glean information from it for display in a "now playing" style plugin or script. After a few days of reading and subsequent testing, I realized that after getting the filter graph address from the ROT I was failing to convert it from the IUnknown interface pointer to IFilterGraph until I had registered "proppage.dll" which came with Windows SDK.
So what I am asking is, is there no other way to glean any information from a remote filter graph without having to register proppage.dll?
You can't call a COM interface from another address space unless you marshall the interface pointers and parameters/return values to and from the other process. For COM, you need to register a marshalling object for each interface that you want to be able to use cross-process. The standard implementation for that is in proppage.dll.
I don't think there is a simple way to access the interface without providing marshalling. If you don't want to use proppage.dll, you can build marshalling code from the IDL files supplied with the SDK and compile that into your own app.
G