-
|
hello again, this is the header file: #ifndef GETAUDIOSAMPLES_H_INCLUDED
#define GETAUDIOSAMPLES_H_INCLUDED
#include </fluidsynth/include/fluidsynth.h>
float *buff[2];
fluid_synth_t* synth;
fluid_settings_t* settings;
fluid_player_t* player;
void setup_synth(char* midi_file, char* sfs[], int nsfs);
void fill_buffers(int n_samples);
#endif // GETAUDIOSAMPLES_H_INCLUDEDand the main file is this: #include "GetAudioSamples.h"
#include <assert.h>
#include <stdio.h>
#include <string.h>
void setup_synth(char* midi_file, char* sfs[], int nsfs){
settings = new_fluid_settings();
synth = new_fluid_synth(settings);
player = new_fluid_player(synth);
assert(fluid_is_midifile(midi_file));
fluid_player_add(player, midi_file);
for (int i=0;i<nsfs;i++){
fluid_synth_sfload(synth, sfs[i], 0);
fluid_synth_program_select(synth, i, i, 0, 0);
}
}
void fill_buffers(int n_samples){
float left[n_samples], right[n_samples];
// array of buffers used to setup channel mapping
// first make sure to zero out the sample buffers everytime before calling fluid_synth_process()
memset(left, 0, sizeof(left));
memset(right, 0, sizeof(right));
// setup channel mapping for a single stereo channel to which to render all dry audio to
buff[0] = left;
buff[1] = right;
int err = fluid_synth_process(synth, n_samples, 0, NULL, 2, buff);
if(err==FLUID_FAILED){
puts("oops");
}
}
int main()
{
char *sfs[1] = {"C:/Users/amran/Music/sf/piano"};
setup_synth("C:/Users/amran/test.mid", sfs, 1);
fill_buffers(512);
printf("%d", buff[0][0]);
return 0;
}I'm on windows and I got fluidsynth from the latest release. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 19 replies
-
|
Probably this issue: #874 Should be fixed in upcoming 2.2.2. Try again with this artifact: https://dev.azure.com/tommbrt/d3638885-de4a-4ce7-afe7-f237ae461c07/_apis/build/builds/5611/artifacts?artifactName=fluidsynth-mingw-x64&api-version=6.0&%24format=zip |
Beta Was this translation helpful? Give feedback.
-
|
nope, still the same thing. |
Beta Was this translation helpful? Give feedback.
-
|
@mawe42 said that maybe we can continue discussing on this thread. I should first thank you for trying to solve my issue and ask if I should provide anything that you need. I also came here to apologize for making you feel pressured and for being (albeit unintentionally) rude. And I just want to add, even if you still refuse to help me, and although I may not have expressed it well enough, I really do appreciate your work. |
Beta Was this translation helpful? Give feedback.
-
|
You did not link against libfluidsynth. |
Beta Was this translation helpful? Give feedback.
-
|
you mean in the complier? I did that. still the same problem but with lines included. |
Beta Was this translation helpful? Give feedback.
-
|
Here is the build log: that's what I got using code blocks. and writing this: I'm not sure if the Here is the code blocks project file if you ever need it. (I changed the the file extension to txt so that I can upload it here) |
Beta Was this translation helpful? Give feedback.
-
|
You're using pure mingw32: a 32-bit compiler which creates a 32-bit object file and then you want to link against 64-bit libfluidsynth by using a 32-bit linker from 32-bit binutils package, which only supports i386 targets, see Also bad: you're mixing up libraries from at least two mingw locations: |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, I'll drop out of this now. Considering your questions here and in #922, it starts to feel like answering questions only so you can later drop everything again because you haven't thought this through in the first place. Or even done some basic research... like checking if pyFluidSynth supports MIDI file playback (which it doesn't). I would suggest to brush up on some C first. Or simply use subprocess.run with pipes and the FluidSynth CLI. Good luck. |
Beta Was this translation helpful? Give feedback.
-
|
logical, still kinda stings. Anyways, you helped me out a ton, I really appreciate it. thank you soo much but before I go, I want to say I only dropped this because of the numbers you showed me (which I had no idea how to come by), it convinced me it wasn't worth it. Another thing is that I came by pyfluidsynth after I created #922. The docs didn't mention anything about reading midi files, I only found how to trigger note-on note-off events and I just assumed it's just outdated and lacks even more features. Besides I already decided I want to create my own bindings (I thought it was gonna be fun lol). It was still a last hope solution tho, that's why I mentioned it.
that's not actually a problem. As I said, I generate the midi files. I can just the note on-off event to the module instead of writing them to a midi file. still, optimizing that is gonna be a pain, and as you just proved: it's not gonna be worth it. All in all, had fun (not really), I finally learned how some projects use multiple languages though. I hope you have a lovely day. Goodbye. |
Beta Was this translation helpful? Give feedback.
-
|
I wrote:
To which you answered:
Then you write:
Now you write:
That literally makes no sense. Please, before contacting somebody else to help you with your problems, spend a few minutes thinking them through beforehand. It will remove a lot of frustration on both sides. |
Beta Was this translation helpful? Give feedback.
-
|
I really should've expressed myself better.
I meant a hope for a speed up isn't my only reason, I also wanted to create some python bindings (for a learning experience), if I wasn't willing to dirty my hand I would've tried pyFluidSynth if it didn't work I'd just move on or figure something else. I also explained why I was a bit turned down from checking out pyFluidSynth first. anyways, I really hope I didn't waste too much of your time. I would apologize if that could accomplish anything. |
Beta Was this translation helpful? Give feedback.
-
|
I'm sorry if that seemed harsh. I do think it's great that you are trying to learn new stuff, that you want to experiment and that you are not afraid to deep-dive into unknown waters. Some suggestions for the future (and I hope they don't come over as patronising, they are well meant): Think about what you want to achieve first, then do some initial research on it. Your questions in #922 were about optimizing fast-rendering a MIDI file. Now you write that you generate the MIDI events yourself and that you are considering pyFluidSynth. So what is it? Are you looking for a fast-way to generate audio from a MIDI file (which is basically just a long list of pre-generated MIDI events)? In that case you are optimizing for throughput and want audio from MIDI events in faster-than-real-time. Or are you in a real-time-playing scenario where you want individual MIDI events to immediately create audible sound, like if you strike a key on a piano? Then you are optimizing for latency. Oh, and about optimization in general: don't try to optimize stuff without measurement and only optimize if you really have a problem. In optimization, your gut-feeling is virtually always wrong. And I say this both from long experience and reading other peoples experiences. If you can't measure, then learn how to measure first. Then double check that you are really measuring the right thing. Only then start to think about optimization. And only if your program is finished and actually does what you want it to. This applies both to technical optimization like latency, throughput, memory consumption... but also to "softer" things like features, user-interfaces and the like. I have learned from this discussion that there are not only cultural differences between people, but also differences in the perception of time. To you "long time ago" seems to mean "last week". To me, it means something further away than a few weeks, maybe months or years. Might be age related, might be cultural. But definitely something to consider when writing questions, reacting to comments or writing answers... for both parties... :-) |
Beta Was this translation helpful? Give feedback.
You're using pure mingw32: a 32-bit compiler which creates a 32-bit object file and then you want to link against 64-bit libfluidsynth by using a 32-bit linker from 32-bit binutils package, which only supports i386 targets, see
mingw32/bin/ld.exe --help. That doesn't work. Get mingw32-w64 andgcc getaudiosamples.c -Lfluidsynth-x64/lib/ -lfluidsynth -o testwill work.Also bad: you're mixing up libraries from at least two mingw locations:
c:/mingw/andC:\Program Files (x86)\CodeBlocks\MinGW.