Ghadjeres
commented
3 years ago Hi, thanks a lot for your interest! And yes you're right. I tried to fix this in #78. On my side, the issue was due to the initialization of the tensor_metadata. When generating form scratch, if the tensor_metadata is not given, I used a tensor_metadata from a chorale from the test set. But there's a problem if the chorale you are trying to generate is longer than the chorale from the test set... So I simply repeated the tensor_metadata over the time dimension. And because LSTMs can take a sequence of variable length, this error went unnoticed. All the best,
P.S.: with long chorales, it can be necessary to better adjust the temperature decay and the total number of iterations to get decent results.
fabianostermann
Hi there! Thanks for sharing this wunderful project, I was interested in having a Bach-Machine for some academic studies on it. I managed to make it work with your pretrained models with ease. Then, I tried to include the generation process of DeepBach in a bash scripted experiment, which ran through successfully: I had automatically produced pieces (midis) with different length. But then I noticed one strange and severe problem of the outputted pieces:
At a maximum piece length of 32seconds (which is --sequence_length_ticks 256 with all other params on default) the optimization procedure of the gibbs sampling algorithm seems to fail. The rest of the pieces are pure chaos, just as if --num_iterations was set to 0.
I've already checked by debugging, that the gibbs implementation is refering at ticks greater 32seconds, and it does. For some reason, it seems that the model fails to predict something meaningful. Since the approach is a LSTM, I cannot imagine why this could be a limitation (LSTM size is 256, but why could that be a problem?). If I'm right, the paper says that only a portion of the past and the future is used for prediction.
Thank you very much for a hint of what I'm doing wrong, or if this behavior is known. Best wishes!