GithubHelp home page GithubHelp logo

rripio / pre.di.c Goto Github PK

View Code? Open in Web Editor NEW
2.0 2.0 2.0 1.11 MB

A preamp and digital crossover

License: GNU General Public License v3.0

Python 99.34% Shell 0.66%
audio python3 digital-crossover preamp loudspeakers

pre.di.c's People

Stargazers

 avatar  avatar

Watchers

 avatar  avatar

pre.di.c's Issues

Some clients need extra time for connection on start

When launching clients on startup some seems to need some extra time as implemented in 5b7779e, even if its ports are up as reported by predic.wait4source().

mpd is the more connection-reluctant as of now, and needs an extra time of 2 seconds, written as time.sleep(gc.config['command_delay'] * 2)

This added wait interval could be a candidate for a separate config variable, since it is more client dependent than machine dependent.

As a remainder, let's note that gc.config['command_delay'] configures a global coefficient for all hard delays in the program, in the hope that they scale well with machine speed.

install scripts

Download and update scripts can be adapted from the FIRtro distro to work for pre.di.c. Some work has been done on my fork

Offtopic

Hola Roberto,
No sé si te acuerdas de mí de la época del SweepScope. Ya estoy muy fuera de la acústica :o(.

Me gustaría contactar contigo. Yo no he cambiado mi email (supongo que si buscas en tu correo por SweepScope, lo encontrarás). Si lo tienes ¿podrías escribirme? Yo tengo el tuyo de la época de "wanadoo", que ya no está operativo. Por no ponerlo por aquí a la vista de todo Internet!

Un saludo y me alegra ver (con envidia) que sigues operativo con el audio
Jose

loudspeaker config helper

Hello I have prepared do_config_files.py: a loudspeaker config helper script.

You can have a human readable YAML file where to define your multiway loudspeaker configuration:

loudspeakers/example2ways+sub/example2ways+sub.yml

Then the script generates brutefir_config and speaker.yml to pre.di.c to work:

~$ do_config_files.py

 Usage:     do_config_files.py   loudspeakers/myLoudspeaker/  [ -w ] [ |less ]

            -w   Overwrites the existing 'speaker.yml' and 'brutefir_config',
                 otherwise '____.candidate' files will be provided.

 This generates low level files needed for pre.di.c to work, i.e.:

   'brutefir_config', 'speaker.yml'

 The following files are needed under the folder 'myLoudspeaker':

   - 'myLoudspeaker.yml':
     The complete full range, multiway, subwoofer loudspeaker definitions including
     pcm names, gain, delay and polarity, as well as target values for SLP and room EQ.

   - 'brutefir_settings.yml':
     General runtime options for Brutefir.

   -  and some '*.pcm' FIR files to be used for XO and DRC.

      (i) CONVENTIONS FOR NAMING *.pcm FIR FILES:

        XO:
          xo.someDescription.pcm

        DRC:
          drc.X_someDescription.pcm     Where X is the channel 'L' or 'R'

Some stuff 'ref_level_gain' and 'target_xxx_curve parameters' still need to be considered manually under speaker.yml.

Hope this helps.

External 'show' command

Something that talks with the running server, instead of a standalone program that has great delays in loading and importing everything needed.

New format for EQ curves

Target curves could be on frd format, and hence a separate frequencies file would be unneccesary.
All eq curves could be calculated on the fly for frequencies in the target file.
A program to interpolate targets on system frequency points from FRD curves could be handy.

allow no filtering in speaker.yml XO sets

As it is already available none for DRC sets inside speaker.yml, it is useful to allow no filtering for some use cases, for example for a full range pasive loudspeaker.

DRC:
  filters: [f.drc.L, f.drc.R]
  sets:
    nearfield: [L_DynA42, R_DynA42]
    none: [none, none]
XO:
  filters: [f.fr.L, f.fr.R]
  sets:
    normal: [DynA42_left, DynA42_right]
    none: [none, none]

This is the code proposal to allow this under the function server_process.change_xovers :

            if XO_set in gc.speaker['XO']['sets']:
                coeffs = gc.speaker['XO']['sets'][XO_set]
                filters = gc.speaker['XO']['filters']
                # allows no filtering e.g for fullrange loudspeakers
                coeffsTmp = coeffs.copy() # a copy does not modify the original
                for index, item in enumerate(coeffsTmp):
                    if item == 'none':
                        coeffsTmp[index] = '-1'
                    else:
                        coeffsTmp[index] = '"' + item + '"'
                for i in range(len(filters)):
                    bf_cli( 'cfc "' + filters[i] + '" ' + coeffsTmp[i] )

Error loading server_aux.py

Hi @Rsantct : thanks for your efforts on the web page.

When loading predic this error arises, here reproduced manually:
predic@predic:~$ scripts/server_aux.py start
(server_aux) bad option

The result is that new functionalities of player communications do not work.

Also, on this line of loading script:
Popen( ['server_aux.py'] ) # if this fails check your paths
you could put the full path with the help of bin/basepaths.py

import basepaths as bp
---
path = bp.bin_folder

or something like that.

Review and try everything PEQ

There are wired paths to (now) predic folder, config files needs update YAML format, and a function in server_process.py is needed.

code arrangement

@rripio says:

Also, I think that we should discuss in advance a bit changes this big, that affects general distribution of code. That is, I would have rather have each player's specific code confined to it's own load script as much as possible.

That goes also for any auxiliary functions, and so leave the bin folder dedicated to the server, that is player agnostic.

Layers of functionality are to be as independent as possible from the server.

Originally posted by @rripio in #28 (comment)

Server response messed up

in general, server response is messed up (by me), in absence of clients to test its validity, usefulness and completion.

input "none" breaks program

selecting input "none" raise an exception in the server, related with gain routines being unable to retrieve the associated gain.

missing DRC_set restore when starting up

When startaudio.py completes, the status shows the last DRC_set in state.yml, but it is not running.

This mod inside startaudio.py fixes that behavoir:

def init_state_settings():
    """restore audio settings as stored in state.yaml
       and takes care of options to reset some of them
    """
    ...
    ...
    # restore DRC_set
    pd.client_socket( 'drc ' + str( gc.state['DRC_set'] ) )

    # XO_set will be adjusted when restoring inputs

ALSA players

I propose to include a little function update_asoundrc() inside startaudio.init_jack() to manage this issue. It can be found here.

Per channel gain correction

Gain correction for multi-input external modules (DVB, an analog input
switcher, etc.) as a server command.

'input none' fails

When issue the command input none a warning appears:

Warnings:
	 Something went wrong when changing input state

It seems that it is missed an early return inside server_process.change_input():

    def change_input(input, state=state):

        state['input'] = input
        # if none disconnects all inputs
        if input == 'none':
            disconnect_inputs()
            return state                    <===== this one fix the problem

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.