@25, fair enough.
#27 (edited by visualstudio 2019-01-30 16:12:41)
i've wrapped it for python
you can check it out on
this GitHub repository.
Damn, I didn't know you could do that. I'm not very well-versed in Cython, or its custom language, am trying to find a good tutorial on it though.
And here's my wrapper around it in C++:
If an error occurs in the library, it throws an std::runtime_error. This was something I just quickly threw together, feel free to contribute or make changes to make it more C++-ish.
Great that you're making wrappers, guys! Always fun to see.
@ethin I think there's a bug in the process method in the C++ wrapper. You are declaring buf, which you use for the output, as an uninitialized pointer. It's not pointing to valid memory - it's pointing to a random address in RAM. It needs to either be a parameter to the function so that the user can supply it, or you need to have something like an std::vector of floats in your class if you want the user to be given a float buffer that is managed by your class rather than by the user themselves.
@30, ah, thank you for pointing that out to me. Like I said, that was something I threw together before I forgot the idea, so I knew it would have bugs. I'll work on correcting that soon.
No worries, I just thought I'd mention it.
By the way, has anyone had issues with vocshell crashing? I got a report in another topic from a guy who says it crashes for him, but I have no further information yet. Has anyone else experienced it?
i didn't try it, maybe it is better to debug it yourself.
Of course I would, if I could reproduce the reported crash. I cannot, which is why I am asking to see if anyone else has experienced it.
#35 (edited by Ethin 2019-01-31 22:37:34)
OK, I just fixed that bug, and squashed some warnings that MSVC reported on /W4 in voclib.h regarding uninitialized variables. Yeah, I know... they're initialized, but MSVC doesn't know that. You can find that slight modification in lines 238-245. It shouldn't affect anything whatsoever since you re-initialize them later on lines 246-306. I just did it so MSVC wouldn't complain about it. I also made a vocshell.cpp file (which is functionally and almost identical to the C version but uses the C++ header) for testing. So feel free to give it a go and tell me how she runs. I also discovered the other dr_* libs for encoding/decoding, I might add those outformats to my C++ shell just for the hell of it.
@Ethin I just fixed a few warnings seen with MSVC about floating point conversions, but I don't get any warnings about uninitialized variables on level 4. I am using MSVC 2017 Community. What version are you building with?
i didn't get such warnings with msvc 2015
Building with MSVC 2017 enterprise. It was c4701.
I wonder what different settings we might be using, then. I have warning level 4 enabled, with optimizations. I also use link time code generation.
I use the command line. Just cl /nologo /W4 /std:c++17 /EHsc /I. vocshell.cpp
@Ethin Interestingly, I did not see those warnings when building with CMake using MSVC++ 2017. However, when invoking it directly I did receive those warnings and have now fixed them, both the ones in the shell and in the library itself. Thanks for the tip!
the Dropbox link gives a 404. Can't you use github's release system to ship the binaries? I don' have a c compiler installed. And re talk box, I do love it, especially for making synths sing, but it doesn't do splitting of consonants so the s buzzes and stuff, I had a hardware vocoder before the flood that would split consonants. I use them to make speech synths sing. But MDA talk box seems to have very low output levels and I don't want to clip it. Maybe this could be better for me. VST version definitely appreciated, it doesn't even have to have a UI, just expose everything via automation so we can envelope it and just change it. There's a certain implementation some vst plugins use to make it so that the sliders are labeled such that if something has modes, for example, a waveform selector will say sine for a while, then you hit page up a few times and it'll say sawtooth, then pulse, etc, instead of just printing a number. Please for the love of god don't use synth edit unless you can make it expose the names nicely, synth edit is notorious for bad automation exposure.
An anomaly in the matrix. An error in existence. A being who cannot get inside the goddamn box! A.K.A. Me.
You're absolutely right that we do need a VST, but I'm not sure I'll be the one doing it. If I'm lucky, someone else will pick it up and do a nice VST wrapper. If no one does, I'll do it. And no worries - I was not thinking of using SynthEdit.
The vocoder does not split voiced and unvoiced sounds at the moment. Personally, I hate the kinds of errors that are often introduced when plugins try to do that. To my ears, those errors are far worse than the slight buzzing that is introduced by not attempting to filter them. Then again, I'm sure that's a matter of taste.
I will update the Dropbox link in the first post; not sure why it is broken as the file is still there. Thanks for alerting me to that!
i am a bit lazy, otherwise i would do that as well.
I really like vocoders, especially the most modern ones.
It would be interesting even if there was the possibility of using it as plug-in vsti, controlling the notes via midi. Here I use a vocoder plug-in that seems to have been abandoned, called VOKKO (Stereo Vocoder) from KLANGLABS, very good.
Already, a question: How do I use it in shell mode? And the carrier and modulator files, what are they? Could you please give me more details?
I did some testing here and it is giving error.
First, what error are you getting? If you can reproduce the text of the error I will be able to help you figure out what the problem is.
I thought about making a VST, and if I do it will definitely respond to MIDI as well. This ties in to your question about what the carrier and modulator files are, actually. The carrier file is what you would hear if you listened to the MIDI that you are sending to the vocoder, through whatever patch you wanted to use to generate the sound. Basically the carrier is an instrument that plays either chords or a simple melody, and this instrument is then made to sound as if it is singing the words spoken in the modulator file. The modulator is the speech that would be coming in through your microphone as you play. It's just that in this case, both of these files are meant to be generated beforehand and the shell then processes them offline. Does that make sense?
I understood, that's what I'd thought.
To test, I'm generating the carrier file using the bgt soundtrack, writing directly to a wav file.
For the modulator file I am using the speech you recorded, just to test myself.
However, when you type the command, the program crashes and the famous windows message appears saying that the application has stopped working.
See if I'm doing it right:
vocshell -c note.wav -m speech.wav -o result.wav
The code in bgt to generate the carrier file is this:
Does the carrier file need to have a specific duration?
Another detail that I believe is not the problem, is that when I downloaded in chrome a warning appeared that it could be dangerous, but I downloaded it anyway because I knew it was not.
@47, ignore that warning for this kind of file -- chrome will do that for practically everything these days.
I think I may have figured out why it was crashing. It was a build flag, nothing wrong with the actual code if I am not much mistaken. Please redownload the file from the link in the original post and try it again.
Let me know how it goes!
The executable link in the dropbox is not working (404) and github only has the code. I do not have the compiler here