Let me write a short document detailing what /should/ go where first.
Am 10. Mai 2016 03:30:02 MESZ, schrieb Geof Nieboer :
>Yes, Wix is pretty flexible in that regard.
>
>It looks like right now some config files are looking in the $HOME
>directory and some are looking in the $APPDATA directory,
Yes, Wix is pretty flexible in that regard.
It looks like right now some config files are looking in the $HOME
directory and some are looking in the $APPDATA directory, so I think we
should examine thoroughly what is looking where and aim for consistency.
Geof
On Monday, May 9, 2016, Marcus Mül
Hi Geof,
is there a chance to manually specify where the config files go in terms
environment variables? I.e., tell the installer to put what is in
PREFIX/etc into %APPDATA%?
Best regards,
Marcus
On 09.05.2016 17:37, Geof Nieboer wrote:
> Tony, that's good news.
>
> The nice thing is that the e
Tony, that's good news.
The nice thing is that the environment variables can generally be made as
relative paths, so I should be able include setting that automatically for
everyone as part of the msi. The $home directory is probably the best
place as Windows doesn't want users changing files in
Thanks Marcus.
I just set the environment variable that you mentioned in the run_gr.bat
file that Geof mentioned and portaudio now works. I realize it is not a
clean solution, but it is a working one. I am happy.
Tony
On Mon, May 9, 2016 at 9:42 AM, Marcus Müller
wrote:
> Hi Tony,
>
> to
Thanks Geof. A Windows audio source would be great. Just to be clear
though, because I started down this path by first trying to get GRC to
process my config.conf file. I never succeeded. Is this a known problem?
Tony
On Mon, May 9, 2016 at 9:06 AM, Geof Nieboer wrote:
> Tony,
>
> Getting t
Hi Geof,
as I'm currently thinking about how we'd want GNU Radio to /actually
behave/ when looking for config files, I'd like to ask you a question
regarding generation of the installer:
How do you do it? Are you letting CMake install everything in a "clean
slate prefix", and then just package th
Hi Tony,
to be honest, I'll be rewriting GNU Radio's slightly dated and slightly
ugly preference system, as it seems, so I'm not 100% giving up on this.
So, I hope the spirit of the workaround was clear to you: you can always
manually set this particular setting via python (instead of specifying
i
Tony,
Getting the Windows audio source to work is on my "to do" list. I
reworked the sink already, so I don't think it will be difficult to do the
source either.
The hard coded paths are troublesome, as using a Windows installer
that allows users to install in any path they desire after everythi
There appear to be some problems with "python module"s in Windows GRC too.
I get an error that the editor can't find a particular file. If I add the
python block in GRC, then have it generate code and add the code to the
corresponding Python file from an external editor - I can then run the top
le
Hi Tony,
> The lack of path separators is troubling.
I couldn't agree more. But since that just means that the separator
get's "eaten" somewhere, and we don't know whether that happens when
generating these paths or just when printing, I'm still full of hope…
> The fact these directories don't ex
The command:
gnuradio-config-info --prefsdir --sysconfdir
returns
C:gr-buildsrc-stage3staged_installReleaseetc
C:gr-buildsrc-stage3staged_installReleaseetcgnuradioconf.d
The lack of path separators is troubling. The fact these directories don't
exist on my machine (even with ap
Sooo gnuradio-runtime/lib/prefs.cc:
77 // Find if there is a ~/.gnuradio/config.conf file and add this to
78 // the end of the file list to override any preferences in the
79 // installed path config files.
80 fs::path homedir = fs::path(gr::appdata_path());
81 homedir = h
The * is actually just an artifact of how that list is generated; it's
written by CMake when gathering the enabled audio engines; When running
cmake, you'll see something like
-- ##
-- # Gnuradio enabled components
-- ###
The * is actually just an artifact of how that list is generated; it's
written by CMake when gathering the enabled audio engines; When running
cmake, you'll see something like
-- ##
-- # Gnuradio enabled components
-- ###
I think I'm making progress with your help Marcus.
The output of "gnuradio-config-info --enabled-components" is:
python-support;testing-support;volk;doxygen;sphinx;gnuradio-runtime;gr-ctrlport;gr-blocks;gnuradio-companion;gr-fec;gr-fft;gr-filter;gr-analog;gr-digital;gr-dtv;gr-atsc;gr-audio;*
port
Huh, can you verify portaudio is in the output of "gnuradio-config-info
--enabled-components" ?
Can you add another section,
[audio_portaudio]
verbose = true
Just to verify: you're using the "[..]" section headers correctly, and
the rest of the conf file looks ungarbled, right?
We might be enc
Thanks, but I've tried that (setting "audio_module = portaudio"). It
doesn't appear to have the desired effect.
Tony
On Thu, May 5, 2016 at 4:26 PM, Marcus Müller
wrote:
> Sorry, not currently running any Windows VM, but in the spirit of giving
> you the info you need as fast as possible:
>
>
Sorry, not currently running any Windows VM, but in the spirit of giving
you the info you need as fast as possible:
Quick lecture of the audio sink/source factory tells me that under
windows, by default the windows audio architecture is used.
So to use portaudio instead, you need to have a GNU Rad
I'm using the pre-built Win64 binary of GNURadio listed on the gnuradio.org
site. The portaudio library was included as part of the Win64 build, but I
can't seem to figure out how to use it instead of the default windows
audio. (I want an audio source and the windows audio source does not
work.)
20 matches
Mail list logo