How do I make a standalone executable application (desktop, on server or mobile apps) in Chuck?
I'm not sure what you are trying to do but two things ...
If you need ChucK to run on another system, just load it.
I you are looking to share your composition, there is a function to write the output to an external file in some audio format such as .wav. That file can be replayed on any other system of you choice. Of course, it'll also play from a web site.
Basically there is no "standalone" ChucK system other than the entire system.
You can't make a runnable app/patch like you can with MaxMSP at the moment. The simplest solution is to just download the MiniAudicle IDE. It comes bundled with a version of ChucK so you can skip over all the command-line stuff.
If you want to make an app for PureData for example, you will need to use libPd to use PureData objects inside your app.
For Chuck you can try to use libChuck, or use Chuck sources in your C++ app.
Related
I'm working on a project in which the user will be able to change windows app icons through an application. Is it possible to have electron perform such a task or is it impossible for the electron framework to actually communicate with windows like that?
I sadly can't proof that but
I think it is possible. You could for example use Child Process and spawn processes that do things for you or write your own c/c++ modules. You can actually write c/c++ node functions, classes and so on, wrap them and use them in nodejs. Here to the Reference. Be aware though, if you don't find any pre-made solutions you have to do that for every operating system individual!
So I recently wrote a chat bot which relies on lua and luasocket to respond to a twitch stream's chat. It's very basic and has various files it reads/writes to. It runs from the local computer. I finally got it working perfectly and now I'm interested in potentially distributing it to streamers who would get the most practical usage out of it.
But I can't just give them the files and lua script; they wouldn't be able to run it. They would need an interpreter and they would need to set up luasocket. With very little experience this is a very daunting task. Even I struggled to properly get luasocket working to make this bot.
So my question: Is there a way to package the lua interpreter and luasocket library such that I can give my bot to other people in an easy to use and practical manner? Preferably a .exe file, but really anything that doesn't require them to go out and set up the entire language and script dependencies on their own.
So, for an embedded project with external NOR flash and existing commercial RTOS.
Can I use the coffee filesystem in a form of a library, i.e. to compile it in? From what I've seen it seems possible, only the dependencies go quite deep in to Contiki. I'll surely dig in, but may be someone have done something of the kind already?
This does look very doable.
From a quick grep in core/cfs/ it looks like there are no Contiki-specific abstractions used in the implementation of CFS. And another very quick search on GitHub shows that swift-nav/piksi_firmware contains and uses CFS without Contiki.
tldr; at bottom.
Ok, so once again an interesting problem and I'm looking for a fun and interesting solution.
My current project involves being very modular, meaning the program functionality will be easily changed based on different modules and the program would adapt.
So I started out with the typical route, which is using DLL plugins. Now this is just way to normal, I want to think outside the box a bit.
The modules included in my program are long running campaigns that may take weeks to finish, and there will be many running at a time. So stability is a big issue, so I thought about what Google Chrome does. Processes, not DLLs or threads.
So I have a framework going and I need a way to get some information about each module (which are now EXEs). Now for my DLL framework I was exporting a "Register" function that would fill in some information.
So I thought to myself, hey EXEs can export functions, let's see if that actually works...It doesn't. I did some research into how Windows handles theses things and I don't feel like hacking the PE headers on the fly (but it's the out of the box kind of thinking I'm going for).
I'm planning on using named pipes and CLI parameters to transfer data between the main program and the module exe's. I could use that in a register fashion, but I want to here other peoples thoughts.
tldr: I'm using EXE's instead of DLL's for plugins. Looking for a way to easily export one time information like a exported "Register" function would on a DLL. Thoughts?
You might still consider having the modules written as DLLs with defined entrypoints (e.g., the Register function). Then you write the executable that loads the specified DLL. Your main application would fire off the driver executable and give it a name of a plugin DLL.
That way it is still easy to define and export the set of APIs that must be provided yet still run it as a separate process. The one executable that you write can load the specified DLL and then handle the necessary IPC with the main app.
You could define a protocol via the stdin/stdout, named pipes, sockets, etc.
I have successfully used 'plain' COM for several projects, and objects inheriting from TAutoObject. The bonusses here are IDL; the interopability with .Net, VBA and other non-Delphi things; and the fact that implementors still can choose wether to supply a DLL, an exe, an NT-service, and optionally run hosted over the network (COM+/DCOM). There may be several considerations you should handle about multi-threading and locking, but I found all that I needed to know online.
You can, of course, not use symbols exported by a (running) exe since it is running in another boundary. But, you can load an exe as an image (as you would do with a library) using LoadLibrary(Ex) and then, use the functions exported by the exe. I have tested (just for fun) when debugging PeStudio. See the snapshot below of chrome.exe loaded in the process space of PeStudio.exe using LoadLibrary.
i have an application which call another console application and pass to it some parameters (console app is a video/audio coverter app) ... is there a way to programmatically "spy" or catch the passed paramters other than hooking/monitoring shellexecute/CreateThread etc ?
Create an executable yourself that just calls the original and passes all parameters on to it. Then move the original somewhere else and replace it with your exe. Your program can then log all calls to it, including all parameters.
Yes, there is - as you write Process Explorer is able to do it, and you could employ the same technique. But AFAIK there's no Delphi translation of the winternl.h file from the Platform SDK, so it is even more tedious and difficult. Also this is extremely version-specific, and there are chances it will break with the next Windows version. It's also not quite clear whether this works for 64 bit processes (from a 32 bit process).
If you really want to do it you will find the necessary information in this blog posting by Matt Pietrek, and in the CodeProject article "Read Environment Strings of Remote process".
If you do not plan to use it for closed source commercial programs then a look into the (GPL licensed) annotated version of the winternl.h file from the ReactOS project would probably also help.
It's a Win32 FAQ since 1992 : just read the PEB.
See on Win32 experts group.