Refactor the singleton pattern using layers.py

[GuSangmo]

Dear @BreezeWhite ,

I am the Korean student who plan to use your awesome library as a pipeline of OMR project.
I really appreciate you for this awesome library 🙇 .
We learned a lot from your ideas( subtasks, many rule-based logics, etc...)

In terms of deployment, I think I can contribute some point to your awesome model.
When inferencing model, variables seem to be stored as global variables in layers.py.
It is implemented as , kinda singleton pattern.

However, when multiple users request the inference of the oemer model,
only one user can access this global variable.

I refactored your function in the way that one can also use local variables.

i.e.) oemer/staffline_prediction.py L320

def extract(splits=8, line_threshold=0.8, horizontal_diff_th=0.1, unit_size_diff_th=0.1, barline_min_degree=75
            , staff_pred = None
            , symbols = None
            , stems = None
            , notehead = None
            , clefs = None
            , global_flag = False
            ):
    # Fetch parameters from layers
    if global_flag:
        staff_pred = layers.get_layer('staff_pred')
    # Fetch parameters from layers
    
staff_pred = layers.get_layer('staff_pred')

If we add one option flag in ete.py, one can pass the parameter with local variable, or register/get layer variable
from global variable.

So my points are,

[1] Could I ask the reason you used this `layers.py` pattern ?

[2] Could I send PR for refactoring code this way?
- If that's the case, how can I test my code?

Again, I really learned a lot from your code.

Bests

[BreezeWhite]

Hi @GuSangmo, thanks for your appreciation to this project. Glad that oemer inspires your work.

Regarding to your questions:

1. One major reason is similar to what you've proposed to modify: the massive amount of parameters that needs to be passed between different processing stages, especially the latter the more. Also during developing oemer, I'm not sure what parameters I will need to pass to different stages. Therefore for simplicity concern, I decided to store all parameters in a 'semi-global' pattern. As you can see all parameters are accessed by layers.get_layer function. The original intention is to by adding a middle layer, further checks can be easily added in the future, no matter you want to add, modify, or delete any parameters.

2. Sorry but I might not have time to review any PR now. You can still fork this project to do your own modification. My test standard during that time is 'if no exception occurs, then it passes tests' haha.

Hope this helps you, and wish you happy developing ^^